In a serverless read-only app, all business logic and state is maintained on the browser.
A possible extension to HTMX would be to allow this kind of offloading to pure JS functions instead of requiring hacky intercepts.
You would still have a clear separation of responsibilities between frontend rendering (by the browser only) and application logic (which only generates HTML as output).
Yet another useless Java gimmick with no support other than 1 single framework, Spring Boot.
If htmx has anything to do with HATEOAS it's going to be ignored out of principle.
Is you problem that there aren't many implementations of it today or concerns with the architecture itself?
HATEOAS (or, as Fielding prefers to call it, the hypermedia constrain) is a necessary component of a truly REST-ful networking system, but unfortunately the language around REST is all jumbled up.
I try to explain why this is here:
https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
and I try to explain what HATEOAS really is here:
https://htmx.org/essays/hateoas/
and I try to explain why HATEOAS has been, by and large, a failure outside of true hypermedia clients presenting directly to humans here:
https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...
In the OPs article, it looks like the only thing going over the line is UUIDs. How does the server know "this uuid refers to this element"? Does this require a sticky session between the browser and the backend? Are you pushing the state into a database or something? What does the multi-server backend end up looking like?