It's not clear to me, but how and where is state managed?
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?
Serverless and static are different. Static sites will likely be limited to maintaining state in the browser. Serverless is terribly named but still have a short lived server with access to request query parameters, cookies, headers, and a database depending on your setup
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).
I've done the same thing with vanilla JS in a service worker. I did it with my HTMF library -- similar to HTMX -- but not production ready and based on forms rather than being able to put your attributes everywhere. I'll have to create a simple to do app with HTMX that shows this same functionality. The Rust one is cool as you can do it with 150kB library. But I can do the same thing with 10kB with just simple JS.
That's because you are using in a JSON API context, where it doesn't make any sense.
HATEOAS (or, as Fielding prefers to call it, the hypermedia constraint) is a necessary component of a truly REST-ful networking system, but unfortunately the language around REST is all jumbled up.
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?