It's basically a class that has pre-written lifecycle functions.
I mean, they ultimately associate lists of properties and functions (methods, if you like) with a component object instance (yes, object) down in the React internals. Sure, access to them is FIFO rather than a lookup table, but that still looks a whole lot like very-weird classes/objects being reimplemented in a language that already has decent-enough ones.
Now, the trouble was certain optimizations and features were probably going to be hard to impossible to achieve while supporting both functional- and class-based components more-or-less equally, and the easy path forward was to let class components become more powerful and functional components slip to second-class (haha), but instead they put object/class-like features in their functions so they could have functions (but very much stateful/side-effecty, so WTF is the point?) lead the way, for whatever reason.
Classes were really easy to compose and automatically easily bring everything you needed into the class. This did lead to some situations where you could over-engineer and get yourself into a bind. You can technically do the same/similar thing with hooks, it just requires a bit more code. Lack of setup/tear down with hooks also means you need to rely on nonces more often.
In general, hooks have a bunch of small, reactive-programming tricks that you learn with experience.