I think this HTML SSR approach have different tradeoffs and uses compared to Single Page Applications.
The HTML SSR works best with a stable connection and being close to the server for good enough latency. Higher cost on the backend is a tradeoff on how much computation/complexity you want to offload to the client, and also what language/framework you want to work with more.
Some HN comments from previous related topics suggest these approaches (Hotwire / LiveView / Blazor? / StimulusReflex / Intercooler / HTMX / Unpoly) fare better with apps targeting a specific region so roundtrip latency is lower. One can optimize the reads with DB replicas + app servers closer to any user, but the write DB is the bottleneck (I think). This also ties in with the feedback that US/EU HEY/BC users perceive the app as snappy enough while AU users feel the latency a lot more.
SPA (properly built) should be more resilient in regards to network stability/condition/latency and expose a lot more offline capability.
I feel like the ideal app is HTML SSR + an app shell to serve some offline capabilities. Scaling the write DB globally is a hard problem though.