Watching widgets/components freeze after an interaction because of a poorly-handled race condition in the JavaScript, dropped or mis-handled/scheduled async requests, and inconsistent cross-component state management isn't any better. It's arguably worse, because now the user has to guess as to whether something is wrong with the application or not and then refresh anyway.

Users don't really know what they want, and I'd wager that most are willing to accept a page refresh if they understood the immense productivity gains that developers like achieve, for a worse "user experience".

> Users don't really know what they want

Users do not care about "immense developer productivity"

You can replace a chunk of innerHTML faster than a full page reload, using a near-trivial piece of vanilla JS.

But a full page reload also clears out memory "leaks", old state accidentally kept around in caches, clinging to DOM nodes discarded long ago, but themselves still referenced by an old copy of a data structure, etc. If you go for a SPA, or even something in between, suddenly being careful about your data structures becomes a major concern to long-term app use, carrying a whole new category of debugging.

https://sr.ht/ is faster than most SPAs I know and it refreshes the page a lot

It's not faster despite being in WiFi

This is a false-dichotomy/straw man. The conversation is about a javascript-heavy approach being overkill. I haven’t seen many arguing for noscript here.

Implementing a form that autosubmits and updates an element takes very little js.

This is trivial with a sprinkling of JavaScript - our pages do update as required after form POSTs, for example.

What makes it a terrible user experience?

Nonsense :)