Htmx defers almost all logic to server side. That's the tradeoff, and it's a major shift from what we've become accustomed to in the last decade (unless you've been writing PHP or something similar).
You provide listening points to various parts of your app, and when something changes, all points listening to that key also make the corresponding call to the server for refresh. It sounds hokey, but it's very effective, very efficient, and pretty easy to wrap your head around.
State on the server side is often a very different animal from client side. Whereas on the client, everything is either JS and/or a browser API, the server side allows for relational databases, Redis caches, and all sorts of other strategies, some based on session ids while others using whatever fits for that scenario. "It depends" but it's not just a library or framework as you'd imagine coming from frontend development.
Htmx is quite popular among folks who prioritize and enjoy server-side development. Svelte is likely more popular among folks who enjoy browser-based development. There is certainly some overlap between the two camps, but that's my take on it.
And why does a backend engineer's point of view on frontend state management matter? Why is a variety of options and strategies for different scenarios ok for the backend but not for the frontend?
The frontend has… a browser. It's a much more constrained toolbox. You are forced to use JS and whatever browser APIs made available to you.
The server side is only limited by what can run in a datacenter. Any language. Any service type. Any scaling profile.
Neither is more "correct". Both have pros and cons. As for why the backend engineer's point of view matters: if you are server-side rendering, you will have a better chance of going faster. A browser will always render HTML faster than JS that generates HTML on the fly, and the server side can always be made to generate HTML faster than a browser could. You can always simply throw more hardware on the server side to speed this up whereas you have basically no control over the performance profile of a random user's browser.
Look at Google search results. It's typically not JSON over AJAX; it's rendered HTML dropped into place. Why? Because every millisecond can be quantified into gained/lost revenue.
You provide listening points to various parts of your app, and when something changes, all points listening to that key also make the corresponding call to the server for refresh. It sounds hokey, but it's very effective, very efficient, and pretty easy to wrap your head around.