With stuff like web sockets/Web rtc /whatever new awesome sauce is out today a lot of that has changed, but that's still really the same spirit of ajax anyway, just with actual persistent connections instead of hacking it with long polling.
You can write a shitty system regardless of paradigms used.
You can write a beautiful system even with painful primitives.
All it comes down to is how much time and talent you're willing to invest, which is admittedly a cliche and non answer, but true nonetheless.
Static HTML only has a potential latency benefit on first load due to the ability to save render-blocking resource roundtrips. For later requests where those resources are already fetched, it only adds bandwidth overhead.
But that cannot help with interactive pages or web applications, and in other cases it can be a bandwidth/latency tradeoff.
High latency is always bad and should be avoided. Serving content from the served contentinent is the minimum requirement for good UX.
I exaggerate a bit to prove a point but the gist is definitely happening, we're just waking up to it slowly.
Going from 3s to 1s would be significant. Going from 200ms to 67ms wouldn't be very significant. There are very diminishing UX returns when going below ~300ms.
When the CSS is cached, this becomes ~200ms. Considering that the roundtrip is 168ms, this means that the vast majority of the pageload is just waiting for bytes to cross the atlantic. The roundtrip to eu-central is 30-50ms in comparison, less than 1/3rd. 3 times faster pageload is a significant UX difference.
Now, the reason we accept it with HN is that HN is just a list of direct anchor tags - the majority of the content is other websites. If the page had been more interactive, firing requests and dynamically fetching content, it would feel sluggish at best.
The difference in UX caused by latency is huge.