Personally, I would say that if you are doing DOM updates via AJAX calls that return HTML, HTMX is just the correct way to do it. (Unless you're using some other solution already for other reasons and it also includes that functionality.)
Sure, you could do the basics of that workflow with twenty lines of your own JS, and save a dependency. But that's the kind of thing that is generally very unscalable, because unless you're very disciplined it quickly becomes a mass of spaghetti. The virtue of HTMX is more in how it channels and limits your code, than in the new capabilities it grants you (which were all in common use as of 2005 or whatever).
Why is it better to render JSON on the server, read that JSON in a separate client app that you also have to write, and then do a bunch of manual DOM calls in Javascript, rather than rendering HTML on the server and letting the browser's blazing-fast compiled HTML parser turn it into DOM for you?
The cost of launch is small-ish compared to the total program cost, but the limitations on launch condition the engineering requirements in ways that inflate the engineering costs. JWST had to be built as an insane on-orbit autonomous origami project because its mirror couldn't fit in a fairing unfolded. Repeat for ten thousand other decisions that are made in order to optimize weight or volume.
If you can launch a hundred tons to orbit for $5M, you can just make a huge dumb cheap telescope and throw a dozen of them up there. Quantity covers a multitude of sins.
> The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top".
I would say it's precisely the opposite.
Say 97% of work done by web pages and web apps in practice boils down to "render some data available on the server as HTML, then show it to the user". For these cases, putting what amounts to an entire GUI framework written in Javascript on the frontend is massive, bandwidth-sucking, performance-killing overkill.
There are absolutely exceptions. Google Sheets exists. But your project is probably not Google Sheets.
I assume "jQuery" here is being used as a metonym for the old frontend style where you would use the jQuery AJAX and DOM functions to query HTML fragments and swap them in. This is only really related to jQuery in that it used jQuery utility functions; under modern conditions you would just use fetch() and querySelector() etc to do the same thing.
It's true that the core concept of HTMX is very simple, and you could probably reimplement any given particular use case in a few lines. However, it is in fact a big advance over the manual HTML-fragment style, precisely because it abstracts over the particulars. Standardizing on a particular, good design is an important benefit even if the functionality of the code is easy.
Alpine is primarily designed to be reused via server templating. You use a single template per component to do the in-HTML side, using the server template's facilities to handle variations as necessary. Then you can factor out complex common behaviors into Javascript using Alpine.data.
It definitely does have a maximum size of project it's suitable for. In particular, it's thoroughly individual-component-based; changing anything outside the component requires tacking on non-native hacks, and doing a full interactive app with it would be a painful exercise. But for adding simple interactivity to a primarily server-rendered web page, I've found it to be quite useful.
Sure, you could do the basics of that workflow with twenty lines of your own JS, and save a dependency. But that's the kind of thing that is generally very unscalable, because unless you're very disciplined it quickly becomes a mass of spaghetti. The virtue of HTMX is more in how it channels and limits your code, than in the new capabilities it grants you (which were all in common use as of 2005 or whatever).