Frameworks like .Net WebForms were created to abstract and hide a lot of this from developers, with things like long encoded strings of "view state" that would be re-posted on each request, by serializing things to the URL, or by saving them to Cookie-backed sessions.
But each of these has issues, from privacy concerns using the URL, to security concerns with the "view state", to concurrency and integrity concerns with sessions.
IMO, the biggest reasons these didn't stand out as huge problems in the early 2000's was because:
(a) we didn't use the web like we do today, and our expectations were very different in how things would work if we, for example, added an item to a shopping cart
(b) most heavily interactive / app-like things that more closely work "the way we expect" today, were either still done as desktop apps (like business software) or were implemented as Java applets, Flash, or something else of the sort
(c) in the rare cases that neither (a) nor (b) applied, it was because some very good engineers put in a lot of work to make it work that way.
Htmx pulls html content from the server and replaces inner|outerHTML with it. A JSON object (of the type React/Vue and presumably Alpine use) isn't a good fit to store html blobs and state.
IMO, it's annoying enough that it's probably not worth it unless you're doing something trivial. If you want to render html on the server you can still do that, but in many cases it is easier to just use custom javascript and maybe even receive the rendered html as json to simply updating pages rather than use htmx.