Generating and caching are orthogonal questions. You can generate stuff, and then cache it. And in fact HN does do a lot of caching.
I wasn't asking how much faster "semantically correct markup" would make HN pages render as a rhetorical question. I'm genuinely curious. If you want to make claims that x is faster than y, you should be prepared to back them up with numbers, not merely with more heated language.
Generating and caching can be intertwined. For example, HN seems to generate an inline script at the top of every page. The script doesn't change nearly as often as the posts do, so that script is sent redundantly at the top of every page. If that script were located at separate URL, set to expire never, every visitor would load it once and never again. If you need to change the script, you can change the linked URL. Doing that can avoid an expensive calculation for the server, but also a network request for the client which could be very, very expensive.
To me, it sounds like the caching you're talking about is on the server side. I think you mean something similar to memoization, so you can avoid doing some expensive query or calculation. That is worth doing, but it's still possible to organize the output of those caches in an inefficient manner, and incur unnecessary network overhead. The "semantically correct" part of the markup being advocated here isn't that interesting, if you ask me. What is interesting is the claim is that you can generate less markup per page, and get the same display.
The balance between the repeat visitor cache behavior and the initial number of HTTP requests and latency for a first-time visitor can get hard to judge. Without lots of time to measure the various alternatives and mitigation tactics, it's best to try and generates as little markup as possible. That's where so-called "semantic markup" comes in. Usually it's just less markup, and does better.
Another thing to take into account is the layout behavior triggered in various browsers by the markup you're generating. HN is pretty simple and should render instantly, but it doesn't in anything I've tested (Firefox, Chrome, Safari). Each of them redraw the scrollbar one or more times. That could be due to the tables.
I am trying to dig up the old benchmarks that created the tables are slow mantra but like all things their is a grain of truth to it. Before IE 5 and the addition of the table-layout CSS property tables where considerably slower and more resource intensive on the browser to render. That being said, the point is mostly moot in modern browsers. While their are differences in performance metrics between CSS and table layout, the reality is, it is insignificant enough to not be cause for concern. Unless you are specifically targeting browsers before IE 5.
I wasn't asking how much faster "semantically correct markup" would make HN pages render as a rhetorical question. I'm genuinely curious. If you want to make claims that x is faster than y, you should be prepared to back them up with numbers, not merely with more heated language.