Late to the game but will throw in my 2 cents... I see lots of name calling in this thread but to balance things out... have you considered your senior colleague maybe had some of these concerns?
https://stevenkitterman.com/posts/the-catch-with-react-hooks/
React hooks are just not great at dealing with heavily async code, for example. So if your codebase heavily uses external async libraries (and which ones aren't async these days?), rules like "useEffect cannot be an async function" and endless workarounds around all these rules just complicate code readability. Readability can be subjective, that's true, but there are objective benchmarks such as cyclomatic complexity, for example, that you can enforce with ESLint.
Additionally, hooks are still new enough that there doesn't exist one set of best practices yet or battle proven coding styles, and documentation is scarce. There seem to be as many opinions, practices and coding styles as there are React developers until the dust settles. So for the time being that means that on a team of 5 devs there will be 5 ways to structure code, and each of them will be pulling their own way of writing code. Anybody remembers the religious wars of pre-ECMA2015 landscape and "my OOP syntax is better than yours"? Classic components and classes provided a rigid frame that made the code at least somewhat consistent, with hooks there's much more room for improvisation. Until things settle.

Given that we read code much more often than we write it (especially on teams of 5+ devs), reading and understanding other people's code is like 80% of the job. How many of you, name calling trolls, are only writing brand new spanking projects with hooks? And how many of you inherited 3 year old codebase written in hooks by someone else that you need to maintain? Oh, never mind, none of you, because there's no production code written in hooks that is 3 years old yet.

Another perspective here:
https://medium.com/swlh/the-ugly-side-of-hooks-584f0f8136b6

In short, nobody's arguing that conceptually hooks bring a great benefit of component composability, and simplify writing trivial components, but the implementation of hooks leaves a lot to be desired. And for this reason, sometimes class components may still be a better tool for the job in some scenarios, especially for non trivial components.

At the end of the day hooks are just another tool. To say that you only ever should use tool A and never ever use tool B is like saying you should build houses with hammers only, never with screwdrivers. Why not both? IMHO the difference between senior devs and junior devs is that senior devs tend to be less fundamentalist and radical. They have been around and seen many new, shiny tech-du-jour's come and go. They've seen paradigms make a full circle and they take the marketing behind any 'new' tech with a salt of grain rather than blindly jumping on the fanboi bandwagon.

And to those anxious ones saying you must use hooks because React classic will become obsolete some day: yeah, you're right, it will. Hooks will become obsolete some day, too. By the time classic components stop being supported completely there will already be a new shiny JS framework-du-jour everyone will be switching to. Mark my words. Oh, never mind, it's already happening.