These are all very, very weird points to raise, except maybe the SSR which is inherently hard to do.
Compared to all that, React is ridiculously simple - it has a very small API surface, different parts of your app are isolated by default and performance optimization is generally very straightforward. As somebody who really loves simplicity, React is by far my favorite UI library at the moment.
I think when people fondly remember simpler times with jQuery, it's not because jQuery itself was simple, it's just that they remember working on less complex applications.
Most websites (including this one for example) still function that way. It works fine. JS frameworks simply are not required for most of the work the web does nowadays - you can add interactivity and immediate feedback where it makes sense very easily with vanilla js.
Not only that, but the “simple sites” that used to need a dev to build (like for a local restaurant or business or something) can now be done by the restaurant owner on WordPress.com or Wix or something without much effort
Many large websites still use server side rendering (in whatever language they want), and js to refresh data client-side as required and respond to user actions, pulling data from the server side. There is no need to attempt to move everything to client-side, it doesn't make the UX better IMO, sometimes it makes it worse.
Keeping most logic and templates server-side works just fine on large complex sites serving millions of people, and it's significantly simpler and more stable for development than react or other frameworks, which seem to be in a permanent state of flux.
Of course, there are different versions of the latter: you can have an entirely client-rendered site, or a site that runs largely the same client-side code on the server for initial HTML renders (like React SSR), or a site that renders HTML from the server and then has separate client-side code to enhance interactivity, or any number of combinations of these and other approaches.
It might have been simpler (what ever that means) but the result was a nightmare to maintain and add to.
It’s almost like just when we’re ready to write some dope Jquery code, it’s time to go write in a new framework.
I can say for certain the best React code we will all write will be 5 years from now, but, it’ll be time to move on to the next one.
If you see no added benefit to having your page run in the browser, then by all means do things the old way, and you'll find that even doing the things the old way is today much simpler than it used to be.
If you do want to create a web application that for a large part runs in the browser, I can only see things getting better every year. The perceived added complexity is simply because we are now doing stuff that's more complex.
TL;DR: Building horse carriages was a lot easier than building autonomous cars.
In both cases, you end up with non-UI wrapper components to provide the plumbing in a tree of components that would ideally be entirely presentational. That leads in turn to trying to separate presentational vs. container components, trying to avoid nesting any kind of container component within a pure presentational component to keep it easily testable, creating more HoCs in an attempt to separate concerns, etc.
I certainly wouldn't describe React as garbage like the OP - but I think whether it's the best choice is heavily dependent on the kind of app you're building. The design choices it has made comes with significant challenges and trade-offs and we should not pretend otherwise.
I'm glad they're putting the effort into making the API simpler and easier to use to address some of those concerns, but React itself has been around for seven years now - the vast majority of existing developments will have been started using versions of React created before hooks were introduced.