Responsive site built via server-side render, with a particular benefit for partial page updates. 90% of the benefit of an SPA but 10% of the code: no api, no moving of system of record for state back and forth between database and browser (it's always db), etc. And you can avoid react.
A common use case: eg in Rails, a user has a table open. you can stream new records to the top of that table as they are created in ~5 lines of ruby (a broadcast on the model, and put the table rows in a turbo_frame with a turbo_stream_from somewhere on the page).
There are real limits to this -- you have to hold the update dependency graph in your head -- but the benefits are huge for small to medium amounts of responsiveness.
My experience has been great with Rails/Turbo and htmx.
I get how there's virtually no API if your client is simply rerendering the entire page each time it gets a ws message, but the article glosses over the partial page updates and just says "place the HTML where it belongs." How would that work? You'd need some kind of API for the client to request page parts and/or the server to tell the client where to place them.