These frameworks have emerged for historical reasons. There was a time when HTML/CSS/JS was much less capable and much more fiddly to use. Libraries and frameworks gradually evolved to both smooth the wrinkles and provide dev-workflow-oriented abstractions (components, etc.).

They do, of course, add their own wrinkles, but at the time of adoption ostensibly the juice is worth the squeeze--at least for whatever real-world challenge a given team (or the broader dev culture) is facing at the time.

---

I'll still use pure HTML/CSS/JS for client projects, depending on the context. Usually for static sites or interactive UI/UX prototypes, both in freelance and day-job (agency, bigcorp) contexts. So far, folks are very happy with the outcomes, but I do vet the fit first. :)

In other contexts like enterprise/SaaS apps, Shopify builds, etc. I won't insist on no-JS or avoiding React/SPAs, as much as I'd secretly like to, but I will advocate for self-hosting and minimizing 3P JS dependencies where we're not necessarily gaining a huge increase in capability in exchange for dev convenience, etc.

It's a balance.