I can't speak in general, but there is one thing I vaguely remember being on the React roadmap as part of the class->function switch that AFAIK never happened (at least it hadn't last time I did a lot of React, which was years into the switch): Because they were pure functions based on props, React-the-framework would have the class-based shouldComponentUpdate built into it and using function-based components everywhere would get a free performance boost.

Instead nowadays people who started with the function form don't know shouldComponentUpdate ever existed and all their React components constantly rerender.

The great downfall of hooks, IMO, is that they allow you to create components that look clean and legible, but act unpredictably because all of your state updates are triggered by variable reference changes. The idea is that this makes your state updates happen automagically so you don't have to think about them, but this is a classic example of an abstraction that works until it doesn't.

Redux mainstreamed the concept of reference changes triggering updates, but I think this is a horrible pattern - we don't even have an operator in JS for explicitly passing by reference, so you end up destructuring large objects constantly in order to change one property and create a new object reference, which is a totally inefficient alternative to calling a render method. Plus javascript developers don't generally think about the concept of passing by reference vs value anyway, in large part because the language gives us so few tools for making those choices.

As a result, there is a class of bugs where the only solution is to change the list of dependency variables for a given hook. It doesn't take a huge amount of complexity for the implications of those dependency trees to bend the mind, and the "clean" syntax of hooks comes crashing down.