This is the "Emperor's new clothes" argument that the FP zealots march out over and over again. I guess I'm among the ranks that can't see the clothes.
I wouldn't call myself a zealot. We chose functional components for a new project on my team as a direct response to problems we were having with maintainability of larger React applications. Specifically that class components tend to get massively bloated over time with business logic, lifecycle based rendering logic, and local state. I was skeptical at first as well. But it turns out that once you start fully separating things out into reducers and actions, the class becomes little more than boilerplate. When you enforce that there are no class members or local state allowed in UI components, it pushes people into proper separation of concerns. The project becomes much more maintainable as you don't have to dig around through components to find out what's going on.
Sure. But the point is that the entire class syntax becomes superfluous once you do that. Everything becomes a pure functional component, and you can just throw in a `useEffect` wherever the need for lifecycle based side effects arises.
You have been doing it wrong. Don't put business logic into visual components. UI technologies tend to be a fad. Business logic needs to live longer than UI technologies, and needs to be separated from UI components for testability, maintainability, reusability and longevity.