A good developer will have good enough fundamentals to be able to break down the code to solve a problem into component parts that are relatively easy to understand, have few places for bugs to hide, and are maintainable (easy to change later), whether those pieces are functions or objects or some combination of both. Unfortunately, less than 10% of developers I've worked with directly (which is a lot) have this natural ability. So the question is what paradigm makes it most likely developers will be able to enter that top 10%. OO has guard rails and decades of documented best practices for developers to learn from. Most of the best practices in FP are just a different way of implementing something that's been a documented OO best practice for a long time. Part of the difference is the FP ecosystem is fond of declaring that this or that best practice that requires a bit more mental effort is suddenly obsolete. So on teams where people don't have their fundamentals down cold (most teams), there should be a healthy dose of OO around.

Perhaps there is a time and a place for teams to transition to a fully FP style, but I think it happens organically as members get more comfortable with the techniques and their benefits. And many teams have some extremely talented/knowledgeable veteran programmers who may never be fully comfortable with a functional style. And that's ok, we shouldn't throw the baby out with the bathwater.

It's quite possible that the reason you feel comfortable throwing out OO is _because_ you have a foundation in it. It's also completely possible you'll realize you've managed to recreate all the problems you thought you were going to avoid by switching paradigms in the new one, just accomplished in a different way. No matter where you go, there you are.