Animations being badly/over used aside, this is a bit of a straw man argument.
If you load megabytes of JS to do animations, as opposed to using CSS, then yes you are just doing it wrong.
Things aren't either exactly right and done one way, or else terrible. You can of course have bells and whistles like animations if your usecase requires them (HN doesn't!) and still have a fast loading site with clean code, if you do it right.
I agree with you. And the animations example was simply one of the bad offenders (merely one of the symptoms of the disease).
The disease is overutilizing buckloads of js scaffolding which is blatant in the majority of the websites right now. Even a small blog now "has to have" the latest xzibit framework which pulls 32 foobar dependencies, all gulped into one huge blob of minified compressed clusterfuck-pack.
Yeah, I guess it is a tradeoff between engineering productivity and performance. Both are features. Past a certain level of complexity it is usually the correct decision to choose the framework and toolchain so that you can deliver and maintain features at all. "Make it work -> make it good -> make it fast" is very relevant here.
Though I agree about what you're saying for blogs and other content sites, where the tradeoff is clearly inappropriate in a lot of cases. With that said, things like https://www.gatsbyjs.org/ offer an interesting '3rd way' here, allowing you to keep the productive toolchain and framework stuff but still serve a blazing fast static content site.
If you load megabytes of JS to do animations, as opposed to using CSS, then yes you are just doing it wrong.
Things aren't either exactly right and done one way, or else terrible. You can of course have bells and whistles like animations if your usecase requires them (HN doesn't!) and still have a fast loading site with clean code, if you do it right.