I never understand all the hate for certain tools. OOP is a tool, FP is a tool, and other programming paradigms are different tools. If you're bad a software architecture and you tend to write convoluted OOP software, you're probably also going to make a mess using FP as well. Applied correctly, they can both be great tools for different problem sets.
Writing something that inherently has a lot of state, like a simulation, game, or user interface? OOP might be a good choice. Working on a backend API that's basically a database wrapper, a data processing pipeline, or something else with less inherent state, FP may be a better tool. Choose the rights tools, design good architectures, and stop blaming the language paradigm.
I do feel OO is the default for almost all companies and that requires a lot of debate to start to change so you can use other tools though. I remember working for a C# shop where I had to do some pretty simple data ingestion and cleaning from the NHS API that would have been fantastic in F# with it’s composition patterns, pattern matching, and type system. However because it wasn’t OO I couldn’t get support and so I had to write a lot of factories instead.
I generally feel the same, although I can say just as a pragmatic issue, the biggest problems I have ever faced in programming by far have been in dealing with poorly structured inheritance systems and object hierarchies in other peoples' libraries. Bugs are inevitable but problems with object hierarchies seem to screw up everything unnecessarily in a way that doesn't happen in less object-oriented functional and procedural languages. Sometimes it feels like this extra layer of ways to shoot yourself in the foot, and the feet of everyone around you.
Strong typing can be a blessing and a curse, and screwing up type signatures through poor foresight can be a problem regardless. But get into elaborate object systems and it can be a different level. When they're done well it's no problem, but when they're done poorly, it's maddening.
Writing something that inherently has a lot of state, like a simulation, game, or user interface? OOP might be a good choice. Working on a backend API that's basically a database wrapper, a data processing pipeline, or something else with less inherent state, FP may be a better tool. Choose the rights tools, design good architectures, and stop blaming the language paradigm.