FP code is often easier to read (the article provides a case to that point).

What gave FP a bad rep is, i guess, Haskell (and the "pure functional approach w/ monad transformer stacks").

Every shop I worked at the devs were already at a level that they'd appreciate FP code: easier to read, refactor and test.

The tendency is also towards FP: see the features in recent Java/C# version. Or languages that gain popularity recently (Kotlin, Rust) are more FP'ish than their predecessors (respectively Java and C++).

The way I tell it is FP gives you more options for where to put the state and how to denote it. There are plenty of environments that let you mix OOP and FP and they're all a little bit funky, but not unworkable. I think the key thing here is the learning curve is a little steeper than OOP-ish languages. And since our universities are now really just trade schools, teaching kids which python libraries to use to feed data into a ML model someone else has built, there's little chance we'll see junior software developers who have been exposed to idomatic functional programming.