You're right that this is trade-off is somewhat inevitable, but I feel like Seattle's traffic is disproportionately bad for a city of its size. Seattle is consistently listed as one of the top 10 worst traffic cities in America and is not even in the top 20 in terms of population.
Have a look at the article. Portland is consistently rated above Seattle according to all kinds of livability metrics. The public transportation is far better, it's more bike-accessible, there are more breweries and coffeeshops per capita, etc. Now, this is not to bash Seattle, which is unquestionably one of the best cities in America. But Portland's strengths outweigh Seattle's for broad swathes of people.
In response to question 1: yes, it often very much is, as the examples that I raise in the article show. It could well be the case that there are better technologies for this kind of thing according to certain metrics, but those technologies don't have anything even remotely approaching the Node community driving them. In open source anything, that is decisive. Erlang is more mature, yes, but the community is small and highly insular. Tornado, Netty, etc. also do non-blocking I/O and the like, but they simply don't have the same inertia behind them. That inertia could be precisely what makes Node stable and acceptable for ever-broader enterprise usage. But overall, my claim is more sociological than technological.
We worked hard on Sinatra support this past weekend. Give it another shot. I've deployed multiple test Sinatra apps painlessly today, which was admittedly far less painless last week.
The AppFog command line tool is very straightforward and even somewhat Git-like: http://docs.appfog.com/getting-started/af-cli. If the "af" gem is installed, "af push" is the equivalent to a "git push." You're right that it's not the same thing, but it's pretty handy.
Extra runtimes (newer versions of Erlang, plus Perl, Go, etc.) will become available over time. They're high priorities for our dev team, as are Redis, Memcached, etc.
I'm not much of a Java person myself, but our dev team has told me that the WAR + Tomcat route tends to work best on AppFog, at least at this point in time. This is also our recommended way of running other JVM-based languages.
Hetzner is simply not a platform-as-a-service. It might be a good deal for a server, but that's not what you're paying for with a PaaS like AppFog. What you're paying for is application lifecycle management, from deployment to scaling to cloning to re-deployment on a different infrastructure, to adding services (like Mongo, MySQL, etc.) at the click of a button.
Serverraum alleine = etwas ganz ganz ganz anderes.
AppFog has "real" support (including live chat with all plans, including free plans). And the business model will prove to be quite sustainable (and bundled with a readily comprehensible pricing model).
Try going into the console and seeing if the app is running anyway. Sometimes 500 errors spring up superfluously, even when things run fine. A small hiccup that we're working on aggressively.
I think that that's a good description overall, although I would add that the free plan allows deployment to all currently available IaaS and hence to do things like run analytics on the different infras to see what works best. But I would push back a little bit by saying that you can run apps getting some pretty legit traffic for free. It needn't be just "Hello world" or sandbox apps.
True, there are still glitches to be worked out. We just entered general availability a few days ago. I would encourage you to give it another shot. Errors of this sort tend to arise somewhat randomly.
There's no mention of disk usage because it doesn't matter and has no effect on price. Pricing is based solely on RAM usage. The thing is, economies of scale in the infrastructure space have made this kind of pricing model extremely feasible on the PaaS side.
They might indeed do that. We'll see. Meanwhile, AppFog will be up and running on dozens of data centers by the end of 2012. Those currently available are just the beginning.
My point wasn't that these things don't exist in other languages. Again, I'm not saying that PHP is objectively better than anything else. I know not to play that game. All that I'm doing is remaining steadfast in my claim that PHP doesn't deserve all the flak that it gets and that the language deserves consideration for a whole variety of use cases. That's all!