The HTMX route that this article is advocating has some value.

My YOShInOn RSS reader works that way and I think it is great -- but it is my own thing and I don't have customers and managers coming to me with requirements and I can build everything with that architecture in mind.

As I see it the basic front end problem is that you click on something and then the page is updated and this updating could be really simple (like you are typing into an autocomplete box and search results appear under it) or it might impact a large number of elements spread all over the page and some applications might be very dynamic and updating dependent on the UI state and can't be figured out ahead of times (imagine a developer tool which has lots of property sheets and tool windows)

HTMX is very simple for the simplest cases, requires some back end framework for harder cases (like a page might have 20 partials in it when it draws for the first time, 3 partials need to be redrawn when you click on something, you need to format a response packet that draws those 3 partials in the right place) and breaks down for the hardest cases. Part of the React puzzle is that we often use React for apps that don't need its full power but hey, even for something CMS-adjacent why fight with unintuitive Markdown (face it!) when you could write

   <MyElement attributeThatMattersToMe="yes">Here's the content</MyElement>

which conforms to your needs.

As much as I love HTMX, I got into it when my dissatisfaction with React was at its peak, more recently React is my go-to for anything from whimsical personalized landing pages to biosignals application that use Web Bluetooth, USB and Serial. Why? I use it at work all day and know how to get things done. I can draw anything at all, even 3-d worlds with A-Frame. That frustrating build system is clearing up.