That said, I'm extraordinarily wary of using Tabletop in production. Instead, at the Wall Street Journal, we use a bit of middleware to "prune" our Google Spreadsheets-based data and then cache it on our own servers. A few brief reasons:
Short-Term Reliability. With Tabletop, your project depends on Google not to rate-limit access to your spreadsheet. Google rate-limits access to their Spreadsheet API, though the thresholds aren't clear. If you're building an app you care about, you don't want to be in the position of hoping not too many people try to access it.
Long-Term Reliability. Your project also depends on Google not changing its Spreadsheets API. If it does so substantially, then — poof! — your project can't access the data it needs. Running your own middleware means that, with just a little work, you can provide your projects with a consistent data format, no matter how drastically Google's APIs change.
Load. Google adds a lot of cruft, like scheme notations, to its API responses. Lopping off that cruft will make your project load faster. In my experience, pruning the API response reduces the size of the data to somewhere between 15% and 40% of the original.
Editing flexibility. With Tabletop, changes you make to the spreadsheet are immediately reflected in your project. Sometimes you don't want that to happen. Middleware lets you update your public data only when you want.
Obfuscation. Anyone with a web inspector can trace Tabletop's live API calls back to the Google-hosted spreadsheet. You shouldn't be hiding anything confidential there anyhow, but I could envision circumstances where you might not want readers looking over your shoulders. Middleware lets you obfuscate the original source if you want.
Anything I missed? Any disagreement? I'm all ears.