You don’t really need to know the majority of what’s in this article to make good apps with React. It goes in-depth into how the framework works. Any framework will look complicated when you look under its hood; it’s meant to make everything possible after all.
Actual React apps are as simple and elegant as a complex (web) application ever could be. Separating your app into functional components where most complexity is always local is a great way to make the application structure as simple as they can be. Where developers often go wrong, is trying to force patterns from other frameworks or languages into React and TS/JS.
The thing about looking under the hood into the complexity of the tool you're using is that is can make you consider my initial question in this thread: Do I REALLY need all of this for my use case?
I think if more people would do this exercise they would find that they don't need it, or at least that they might need some form of state reconciliation, but not enough to really warrant all the complexity the tool introduces. Some will find that they don't need it but will still use it for other reasons, like familiarity or because that's what their team uses.
Actual React apps are as simple and elegant as a complex (web) application ever could be. Separating your app into functional components where most complexity is always local is a great way to make the application structure as simple as they can be. Where developers often go wrong, is trying to force patterns from other frameworks or languages into React and TS/JS.