This is what they do.
At the moment if you go to https://twitter.com/#!/twitter then it loads up the HTML for https://twitter.com/, if you're logged in it will be the tweets of those you follow. Then the javascript magic loads in @twitter's profile dynamically.
PushState will allow twitter to load in the static HTML for @twitter's profile at https://twitter.com/twitter/ and then progressively enhance it with javascript. The net gain will be that the page will be available much faster on initial page load.
Twitter is sending down the home timeline as HTML. In fact, what most people are looking for when they go to twitter.com is their home timeline so I'm correct, this is what they are doing (at least in new-new-twitter which I think almost everyone now has). You're also correct, when you go to twitter.com/#!/n8agrin you get your timeline in the background which is then replaced with my tweets. However it wasn't always this way. At one point in time, going to twitter.com just downloaded a bunch of javascript and an HTML bootstrap. The whole site was generated by javascript. I know this because I worked on it.
Technically pushState doesn't really have anything to do with the practice of progressive enhancement or making anything "much faster". You can make pure javascript sites very fast, you can make serving straight up HTML very fast, you can progressively enhance HTML without pushState. pushState is really just a way to manipulate the history of a browser, while optionally changing the browser's current url, without a page refresh (read more here: https://developer.mozilla.org/en/DOM/Manipulating_the_browse...). You can use it to do a lot of things, one of which is to have it serve as one part of a solution for sites that behave like single-page apps without having to resort to the fragment identifier (http://en.wikipedia.org/wiki/Fragment_identifier), forever vilified as the hashbang.