Too many people today are being pointed toward React to do very simple things, like a single-page site that is nothing more than a little text, some images, and a few links out to various other places. These sites could easily be HTML/CSS. There is a lot of complexity for the sake of complexity on the web right now.
The worldwide jobs program that is modern-day Javascript would have you believe that elaborate front-ends are necessary to give end users the experiences they expect, which is an utter pile of lies. What users want is something simple that works.
One of the worst feelings is building a site without a view library like React, getting 80% there, and then realizing you absolutely need dynamic functionality and/or state management because the project's scope changed or started calling for it, only to realize you now need to refactor much (or all) of the site to make it easier to maintain across the board.
This is why I reach for a view library like React, Vue, or Svelte, even if I'm creating something simple. This is because I'm familiar with using these and they provide me with the ability to implement nearly any kind of dynamic functionality or interactions I could want, fine control over component lifecycle, and tight integration with my CSS library of choice to speed up development.
End-users are none the wiser, that is of course unless I do a terrible job using these tools.
For personal projects I usually use Astro[1] solely because 90% of the stuff I am making doesn't require anything more than basic HTML/CSS and maybe a couple static components, but I also have the flexibility to add SSR rendering or even more dynamic components like Svelte without making an entirely new project.
Astro is an excellent choice! I've never used it, but always wanted an excuse to. I think it blends the best of both worlds, and the fact that you mix various view libraries is powerful!
I have a suspicion the reason most people reach for a framework is primarily about two different things: modern tooling (modules/bundling, typescript, etc) and templating. They don't really "need" a virtual dom diffing rendering pipeline, but the fact that you get all these other things out of the box with little setup is what makes it the go-to solution.
Then of course you're left to reimplement basic browser functionality that you now lost (or more likely, you just grab another package that solves that and throw it in your payload).
Not in a way that scales, if you need it. It all depends on the problems you're trying to solve, and if it gets to a point where I feel like I'm reinventing any of the popular frameworks, I'm just going to use them instead.
