I've been reading articles like this for forty years.
And unlike most of them, it feels like you know what you are talking about.
But I predict in twenty years I'll still be reading articles about how functional programming is the future.
Let's start with the number one issue - state exists. But in a completely immutable world, there is no state at all!
In real-world applications, there is an actual state, and it changes. People open and close windows, register and deregister, database tables are updated, files are written, URLs are hit.
Yes, I'm quite familiar with all the ways that functional programming can handle things like state, but the fact is that in a real-world program, there is a great deal of state, and much of the logic involves manipulating it.
Somewhere in your code there will be mutations. You should be keeping a firm grip on these mutations, because that’s where the danger is, but you cannot “functional” them out of existence.
Secondly, the vast majority of real-world human activities are procedural, not functional.
I get up in the morning, relieve myself, brush my teeth, make coffee - all these actions are naturally expressed as state changes.
Remember, me getting out of bed isn't just a property of me, it's a property of the bedroom which is a property of the house.
To see me getting out of bed functionally, you'd have to think of a new copy of the entire universe created where I was in a new state!
This is why everyone naturally reasons better procedurally than functionally.
And very few teams involve a lot of geniuses. Most involved a few brilliant people, and then a lot of fairly smart, competent people, often quite young.
Understanding a sequential list of mutations is easier than a chain of function calls even for people like you and me who like functional code.
Third, a lot of key areas in computation cannot be expressed functionally in any useful way. For example, building a neural net involves iterative, gradual mutations to an extreme large matrix in memory, or the typical GPU operation involves writing a huge number of polygons onto an image.
Fourth, objects aren't just for code, they're really useful for discovery of software functionality.
Just today, I had to figure out how to get very specific somewhat obscure information out of an open source library we were using. I simply went into the REPL, constructed the top-level object, and then started to play with it, looking through the methods and members to see what was going on, which lead me to the correct solution quickly with really very little typing indeed.
This library is fairly well documented, but this was not in it. Reading the code, or even the documentation, would have taken hours.
Beginners discover code that way too. Handing a bright beginner the Python REPL and showing them how to use dir() and help() is a lot of fun!
Fifth, to be a little blunt, you seem to be unreasonably angry at object-oriented program, as if many years ago someone's object had pissed in your teacup. I read your whole rant on OOP and I don't know where to start!
Don't get me wrong - object-oriented programming is an overused tool. If you need to perform some new operation, your first thought should always be a new pure function.
But OOP is overused because it's extremely useful and it's easy to make progress, particularly in a team.
The reason you see a lot of bad OOP code is Sturgeon's Law - ninety percent of everything is crap, and that extends to code, OOP or not.
I think a lot of your rant could be summed up like this - "I worked in a couple of dysfunctional organization, and I have conflated their terminal incompetence with an essential flaw in OOP."
You see better code in functional code because you see a better class of programmer writing functional code, and that's mainly because you can get better results by moving toward a functional style, and partly because smarter people get bored easier and want to do something clever.
OOP and functional approaches complement each other. Both should be part of any professional's toolkit.
