Arvel Gentry must be mentioned, he transferred much of the aerodynamics research to sailing with an amazing series of magazine articles. He debunked a lot of faulty theories, like how the slot works, in a meticulous but approachable style.
Frequently at design time you don't know enough. This is exactly why SQL is great, it is incredibly flexible, it can also allow you to get in your own way, this is just a feature to help detect that.
For example, imagine a system where items are soft-deleted immediately upon user action, but not actually deleted for a few days to facilitate restoration (recycle bin).
There is going to be some nightly/hourly/scheduled job that actually really deletes these records. Initially it will have little work to do, but over time as the system grows it may become slow. Typically this would be hard to separate from other slow queries, you would have to catch it running while causing other queries to pile up. Query time isn't necessarily useful here as you may have enough I/O to cover the slow query replacing pages in the cache, but that I/O would be better serving user facing requests instead of this cleanup job.
This feature allows for the "work" it really takes to serve the query to cause it to error, instead of time which may grind down for other reasons. At this point you know its time to re-think the soft-deletion strategy, you disable the job. Maybe you sweep more frequently? Maybe you keep a look-aside of things to sweep to avoid scans? Maybe you sweep during a low-traffic time? Whatever. It buys you time to think.
I'd love to see a explanation of the security implications of each flow. As I understand it the "most secure" flow is OAuth 1.0a (three-legged), but its a total pain so it is mostly avoided. OAuth 2.0 is dramatically simpler, but there are bespoke additions (Google and Facebook come to mind) that you have to handle, typically in the name of security. I am ignorant of all the implications and would like a guide.
You don't have to re-learn puppet/chef/cfengine/bash script every time. You learn it once. It requires much less effort to "maintain" than manually updating more than 1 box.
For backend nginx instances (we use nginx to balance application servers, and nginx right in front of Unicorn on those application servers) use the Real IP module to have logs transparently show the original request IP not the load balancer's IP.
I have similar troubles with the mobile application when in "low signal" environments. It should decide to swap to local or do a better job buffering, but having 1 bar is not going to sustain a stream.
You are thinking too hard. Just pick one, you can always change later.
All of the options you have presented are "Very Good" - they do so many things right. To steal a pithy quote from my co-worker: "Its a balloon squeeze."
This decision will not determine the success or failure of your business, move along.
There could be a revenue stream in here. They're limiting how many free users an application may have, but I would expect they could charge Tweetbot to have more users. Tweetbot could simply build this cost into the software.
This is why nginx gzips the body before writing the headers out.
You can use 'chunked_transfer_encoding' to enable chunking, combined with 'proxy_buffering off', your backend can stream the body and nginx will gzip the chunks. Disabling buffering has other consequences, so be sure to read up and experiment before you go to production.
http://gentrysailing.com/magazines.html