Let's go strait to the point : I don't like Hooks because they are not intuitive to me.

Classes are so intuitive that I love them.

class App extends React.Component {
  state = {  }
  componentDidMount() {}
  componentDidUpdate(prevProps, prevState) {}
  componentWillUnmount()
  render(){
    return()
  }
}

It's almost if there is a README to understand what's going on there.
I became a developer at 30, two and a half years ago, and I started directly by learning #JavaScript30 by Wes Bos, then React for Beginners. I knew nothing about programming : classes, whatever... but React was so straightforward to embrace that it was a pleasure.

I can't say the same with hooks.

const App = () => {
  const [someState, setSomeState] = useState(initState)
  useEffect(() => {
    return () => {}
  }, [])
}

OK, much less code I have to admit.
useState is easy to get, I also have to admit. For a simple functional component which needs a state, this is great. But for more complex component, actually I would say as soon as an equivalent of componentDidMount is needed, I much prefer classes.

After two projects and two months full time on hooks, I am still not confident how to clear a timeout, how to use an effect only on mount. I start to be confident on fetching async data in an effect, but that's it. OK, refs are quite straight forward, I also have no problem with them.
But what about the useCallback ? Sometimes, quite often, but not always, when I call a callback in my effect, I am forced by my linter to use useCallback, and I couldn't tell you why some times yes and why some other times no. Maybe I need a few more weeks to be fluent in Hooks, but as I don't like them it might be more...

I am working for the first time with a friend, on a hooks project for the last two months. My friend is chasing the code lines, to reduce them at max, and he is also chasing code readability. He is quite an experienced programmer, so I learn quite some stuff from him. He doesn't like redux, so I had to think without it, it was great. And he loves hooks, so I had to deal with them, no choice.

And I'll remember two philosophical principles out of my bad experience with Hooks :

• if a piece of code with less lines is less understandable than a piece of code with more lines, use it with more lines
• a good API is an API where the README is as small as possible, and the number of times the need of going back to the README is as little as possible.

Sorry Dan, but from now on, I'll keep hooks for stateful simple functional components, like forms. But whenever I can, I will use classes.