And I really dislike React hooks because it is so, so "viral" to the code base - "viral" in the sense that any non-component that uses a hook must also be a hook; and so, before long, either the majority of your application code becomes hooks for no other reason than the fact that you want to use a hook deep in the call chain, or you take the hook out and keep passing the argument down.
For me, "hooks" in other frameworks/libraries that I have encountered don't work like that. Usually, the hook is something static and predefined by the framework/library, and _my_ code attaches to those hooks. The way you explain React hooks sounds like we're _conjuring_ hooks in the components willy-nilly, and then attaching things to them. However, I have never found an explanation for the name "hook" in the official React documentation; the explanation might be somewhere in the documentation, but I never found it.
If they aren't using one of those (or more rarely one of the other built-in hooks), then they probably don't really need to be hooks and should just be plain functions.
I've actually voiced similar concerns in the past, though also about the fact that they can lead to render loops that are hard to debug in more non-trivial use cases, vs a simple shouldComponentUpdate method: https://blog.kronis.dev/everything%20is%20broken/modern-reac...
Of course, we are certainly in the minority and many people seem to enjoy React with hooks more than most other solutions out there. That said, personally i think that class based React, Angular or Vue are all (sometimes) more pleasant to work with and reason about. Then again, i prefer the likes of MobX to Redux as well.