[SPBesui]

> The original class components were much easier to understand.

Class components only made you feel like they were easier to understand because the method names indicated an intuitive lifecycle. But the reality under the hood was almost certainly different than your mental model because the method/event handler names were actually deceptive. Hooks are much closer to the metal, so to speak.

> A backend developer could open a .tsx file and understand what is going on, and make simple fixes.

They might assume they knew what was going on and how their "simple fixes" would affect execution, but that would probably be naïve. But that goes for anyone jumping into any codebase for a platform/library that they're not familiar with.

> Hooks makes some things easier but the cost in terms of loss-of-intuitiveness is huge.

This is fair, although I feel like the learning curve for React is only steep at first, then plateaus for the vast majority of application developers. It only gets really complicated (as anything does) when you start to get into advanced performance tuning or you're writing a library with very specific requirements.

> The other mistake Facebook is making is assuming that performance is the most important attribute of a UI framework.

This is simply not true. The React team has indicated many times over the years that basic, hello-world level, idiomatic React code is fast enough for the vast majority of applications ("don't worry too much about the number of re-renders," etc.). They're very anti-premature optimization as a group.

Also, Hooks weren't introduced to improve performance anyway (at least that wasn't the primary motivation).

> handling deeply nested objects in the state without making entire copies of the data

It's not from the React team, nor is it specific to React, but have you tried immer? https://immerjs.github.io/immer/