There are two reasons why sites fall over in cases like this: CPU saturation, where the solution is better caching (which includes going fully static), and network saturation, where the solution is either to get fatter pipes or to reduce the data transferred. Hugs of death are normally due to CPU saturation.
But in this case, I suspect that the server is just saturating its network connection because of poor treatment of images.
I have JavaScript disabled so maybe it’s loading more if you have JavaScript enabled, but when you exclude images, it’s only transferring about 152KB. Images are where it goes wrong: it’s serving up a large number of images, and some of them are unreasonably large and high quality (like 34ᵗʰ place, a 1000×1000 PNG of a fractal being shown at 400×400), and most significantly it’s using quite a few multi-megabyte GIFs, which is flatly stupid and wrong and they deserve to have their site fall over for pulling that.
So the end result is at least 20MB. 20MB = 160Mb, and if your server has only a one gigabit link (very common), you can suddenly only cope with about six visitors per second (though in practice things will start falling over before that, maybe round down to five), which is not quite enough for the peaks you’ll get when high on HN, and it becomes a bit of a cascading problem, kinda like a capacitor but bad.
The solution is to treat the images properly: actually compress them, use videos instead of GIFs, that sort of thing. I reckon 3MB total is readily attainable here, which would allow you to serve 40 visitors per second, which is probably enough.
So yeah, putting your pages on a platform with really fat pipes will solve problems like this after a fashion, but I’d argue that it’s not really solving them, it’s just letting you get away with doing a bad job and shifting the burden onto users.