Isn't "they could serve direct links as static HTML" the whole point of this discussion?For me the point of the discussion was the claim that the first-load performance of a fat-client app is inherently terrible.
This is false.
It is a straightforward optimization problem. Twitter didn't care to optimize.
I don't think it is under debate that the overall responsiveness (after first-load) in a client-side app is heads and shoulders above anything you can achieve in the request/response paradigm. Network latency is real, AJAX can mitigate it but instant response is only possible when you don't hit the server.
So all we're talking about here is the specific (important) case of the initial page-load. As said above, that case has tons of optimization potential, up to the point where it's near indistinguishable from a regular HTML page-load.
Gmail is not a good example to support your case
This may be subjective. Yes, GMail is slow. But it loads faster than twitter for me, despite being significantly more complex. I also imagine google has less incentive to optimize the first-load because unlike twitter users rarely follow deep-links to gmail.
Now imagine twitter applied only the little optimization that google has to their much smaller app - the latency problem would probably not exist. And if that's not enough, I can only repeat: It's a valid approach to serve static HTML for direct tweet links (or just for everything) and upgrade it asynchronously.
My point is that it's very possible to optimize this problem away where it matters (deep links to tweets). I've done it myself a couple times. It's nasty gruntwork, involving endless Firebug sessions. Crying Foul and "this is not possible" is a lazy cop-out.