I'm not sure why you think you're disagreeing as my entire comment was explicitly about how the issues people blame on hooks existed before, but that hooks changed how they were presented/encountered. I literally began it with: "These problems are not really new with hooks. They're actually problems which existed in some form in the class component API."

As the rest of my comment points out, the thing hooks did was make these issues more tractable by reducing the places it was possible to make them. Instead of worrying about which logic is needed between the constructor and over eight lifecycle methods (the number of these was reduced over time of course) for your components, you just have to ask "what does this effect depend on?", "What should it do?", and "how should it clean up after itself?".

This reduces the number of places it's possible for bugs to appear but you can still make them. I believe people blame things on hooks because it forces them to confront those (often extremely subtle and hard to catch until it's too late) bugs earlier by putting them front and center, especially with a lint rule. This is good.

In addition to all that, we also got two major other advantages: sharing of logic/composability and making code using hooks much more minifiable than class components (unlike functions, object properties can't be mangled/shortened by minifiers). Plus we get a vastly improved DX because of fast refresh, which is an excellent bonus.