My context here is a mostly server-side application using HTMX, where I wanted to add a few small bits of additional client-side code. I tried to do it without any libraries but rapidly realised that Jquery would simplify things a lot, and managed to do ok with that, but was still fighting HTMX throughout, and I ended up with a lot of poorly managed local state quite quickly. It doesn't take much complexity to need some better form of state management, and something like React provides some direction there, but of course there are other options, my point was only really to say that HTMX will not do any of this for you, and may get in the way depending on what you need to do.
I kind of see HTMX as discouraging the traditional SPA-ish state management approach though. Or, it could be that the idea just gives me peace of mind. But, the idea being that you manage state less on the client because you're updating the UI with DOM content generated on the server versus rendering from local state on the client.
In practice, of course, avoiding client-state can be tough, especially as you go from sprinkling in limited dynamic interaction to a full-on SPA experience. I'm a little different though, in that I'm not sure SPAs were ever a good idea—at least without shifting completely away from building directly on Web idioms like DOM, HTML and CSS.
Yes, it can be used to render the entire UI app with rich state management across all pages, routing, etc.
However it can just as simply be used to render 1 complex part of an app that has an isolated but possibly complex state. In this scenario I think sprinkling react is reasonable.
At that point, you can just write your own Javascript functions / classes for rendering, and handle your own state management
HTMX lends itself more to "sprinkling". Its basically just a very compact version of fetch(), combined with trigger logic (e.g. setTimeout(), onclick, etc.