I think a lot of the problems the author highlighted become more apparent as the number of devs in the codebase goes up.
If one member doesn't understand all of the nuances of useEffect or paint useCallback, they can write a component or custom hook that another team uses and gets subtle bugs from.
For example, I need to look inside of a hook to see whether the callback it provided was wrapped in useCallback. That means I can't truly rely on the abstraction since I need to learn it's internals.
Pretty much this. I've owned entire applications and it's really fun when you're working alone. But adding a new developer that does not grok hooks (mostly because they are more use to imperative patterns than functional ones), and you will have bugs to deal with almost every single day. In a project, I was using Firebase as the backend and hooks allowed me to nicely abstract it away and use a language closer to business domain (like `useEntity(entityId)` and `useCreateEntity(entityData)`). Everything was more modular from changing the backend layer to breaking up bigger components.
If one member doesn't understand all of the nuances of useEffect or paint useCallback, they can write a component or custom hook that another team uses and gets subtle bugs from.
For example, I need to look inside of a hook to see whether the callback it provided was wrapped in useCallback. That means I can't truly rely on the abstraction since I need to learn it's internals.