There have been lots of requests (even back in b2) for building static HTML front pages so sites with many hits to the front page can get a performance bonus.
While I do believe avoiding trips to the database for common views such as the main page is a good idea, I find the flat HTML concept a but archiac (and MT/CGI-ish!) since comment counts clearly are too dynamic to be "flattened" and it also prevents other dynamic applications from working on the front page short of a complex SSI framework.
I suggest using object serialization to cache data. Once the front page's worth of posts has been retrieved from the database, WordPress can create a cache file and write the serialized resultant object into that file. On next access, WordPress will identify the hot cache, pull out and unserialize the string and boom! all of the recent post data is in memory without going through a database search. This method allows comment counts to stay purely dynamic AND other dyanamic applications keep working.
Suggested implementation ---------------------------
In blog.header.php, the last line says
$posts = $wpdb->get_results($request);
We want $wpdb->get_results() to be able to detect if a front-page-non-specific view is being used (by looking at the query string and making sure select-modifying variables are empty()). If it is a front page view, get_results() will attempt to look for a hot cache file, read its string, and return the unserialized value.
There will need to be a function that does the actual front-page query and populate the cache file (not too tough right?). This function needs to be triggered upon new post and edit post. Function should check the time stamp of the new/edited post and compare it with the last timestamp of the cached posts.
If the WordPress team likes this idea, I can work on this over the next 2 days and send in code bits of my implementation (unless you think you've got it down ;-).
If anyone thinks thereis a better way besides using serialization...well YOU'RE WRONG! j/k ;-) Correct me!