Well, that's a refreshingly reasonable approach to frameworks!
I agree 100% that the biggest challenge solved by many of these frameworks is state management and, more specifically, capturing and reflecting state changes in the UI. Just seems that most frameworks start addressing this single issue, then get greedy; metastasizing their way up and down the stack. Suddenly, you're completely hooked in, using npm or similar to generate tons of boilerplate with framework-specific templating and a mini language, on top of a custom build process.
So, simplicity is kind of an amorphous concept here. Maybe you pick up the binding, but you've traded away a lot for it. I haven't had much experience with React, and maybe it does a better job of confining its intrusions to view state management. But, with Angular and others, I have seen and experienced these huge learning curves that make sound developers' heads explode. Like anything, we eventually get it and it becomes second nature, so the perceived complexity is hidden to some extent. So, we tend to say, "hey, look at this neat binding that simplifies my code". Meanwhile, we're completely overlooking the learning curve, boilerplate, build process, and MB-denominated framework file sizes.
>potentially being less flexible if the project’s needs change later as the big disadvantage
Interesting take, as it's usually the reverse you hear: that is, without a framework everything will devolve into utter chaos as the project grows and takes on new requirements.
My take is that, framework or no, at the end of the day nothing can take the place of good design. And, I guess that's really my larger point here. People tend to offer up "framework" as the one word answer to Web development these days, and I don't think that's a healthy state.