I personally believe almost the opposite. Even when I write Python, I use classes sparingly and if I ever choose to get a lower back tattoo it would probably say “Inheritance Sucks” in Chinese or something.
Think of a constructor function for a class. It is so easy to shove new complexity in there. Just add new optional arguments, assign them as instance attributes, and off you go.
If you have a class like MonthlyReport, and all of the sudden your boss wants to know how many widgets per month you sell specifically in Narnia, well you can probably hack this into the existing methods of MonthlyReport very quickly.
Doing it once maybe isn’t so bad. But doing it a dozen times quickly leads to a bunch of functionality shoved into MonthlyReport that probably shoukd be refactored out, and lord help you if your boss all of the sudden says you need all of it to go into DailyReport, and you need a new YearlyReport class with overloaded behavior for FiscalYear, CalendarYear, and NarnianYear.
If I heard about a system like this, my guess would be that it’s got a crapload of copy/pasted code, constructors and general class methods with huge lists of parameters and switches, maybe a few subsystems where someone tried to rewrite this with misguided MixIn patterns and abstract base classes, and everyone is terrified to change anything because no one knows how it actually works.
Even an imperative design that just used boring modules of functions, maybe with a tiny amount of metaprogramming like decorators for repeated logic, would be waaay better, no functional programming needed. But well-crafted functional programming would be better still.
The problem is sociological. Business managers won’t tolerate being told, “No. I cannot get you this result for a daily Narnian calendar by tomorrow— for that, we’ll need to draw up a quick design plan to make sure we add it in a maintainable way.”
Functional programming mostly requires saying no, being careful, measuring twice and cutting once.
With object orientation, you optionally can push back, say no, and try to do it carefully, but you don’thave to because of all the different buckets of mutable state, you often can find a place to shoe-horn unplanned complexity in somewhere, and leave it for future people to worry about when the shoe-horned complexity causes a big problem.