The example on the blog post is one of those that makes me severely question HTMX and the stuff that we're doing. Doing HTTP requests to increase a counter, or affecting any local-only state change at all, seems so wild to me.
However I think it's a powerful solution to updating the DOM when state changes on the backend and a roundtrip is required anyway. For that matter the examples on the official project site are better to understand proper use cases for HTMX [0].
Personally I use Active Search and Edit/Delete Row a lot. While Active Search does not change state in the backend, I found it's still a valid use case for HTMX when searching large data sets, since the backend is (in my case) just way faster to search through a large data set.
It all comes down to your ability as a developer to find the proper solution to the problem at hand. A counter does not need HTMX.
If you’re using an HTTP request to update a counter, it would be to update the persistent server-side state of that counter (which you’d also do if you’re using React and a JSON API).
No one is advocating for using HTMX for purely client-side state. They’ve been very consistent about this, recommending Alpine, vanilla JS, Stimulus, Vue, and so forth when you need pure client-side state.
For example a like counter wouldn’t be much good if nobody else can see your like.