Tornado is solid and proven, however we will explore gevent on uwsgi more in the future. Using gevent for comet/async would enable us to consolidate the Tornado code into Flask, but we have been focused on other stuff so we'll test gevent when we have more time.
Flask is at about the right level of abstraction for what a Web framework should be these days. In this era of the social graph, it can be more interesting to store your social graph in a graph database and use it as your primary datastore. And if you're not using a relational database as the primary datastore, why would you want a framework that's built around an ORM?
ORM-based frameworks are ok if you stay inside the box, but they can get in the way when you're not using the RDBMS for authentication and authorization. And when you strip out all the stuff that's tied to the ORM and auth, you end up with with something that looks a lot like Flask. It's usually cleaner to start with something that was designed from the ground up to be a polyglot framework.
P.S. We chose uswgi because it's high performance and high quality (Roberto is a really smart guy), and there's a little-known feature in works -- uwsgi binary connectors to varnish and haproxy that will enable you to connect uwsgi directly to varnish and haproxy over a binary protocol and thus eliminate the HTTP overhead.
At scale yes. They're built to solve different problems and excel at each individually. Nginx can proxy, but HAProxy is more flexible. Nginx can cache, but Varnish is much more flexible and efficient. We use all three technologies and route the traffic to the service best suited for the traffic.