Back then OOP was paraded around as the silver bullet of software engineering some people rightfully pointed out that many problems do not map cleanly to OO abstractions. People tried to force all code into that straightjacket anyway, most infamously Java, and thus we ended up with things like "Singleton"s and "AbstractFactoryFactory"s.
Yet OOP was a success, because most problems can be expressed in a decent to good way using that paradigm, and it forced some structure on bad programmers. In contrast, most problems can not be expressed in a straightforward way in FP and the advantage of forcing structure on bad programmers is mostly gone.
I think the current FP fad is actually an unfortunate side effect (pun intended) of the OOP craze. All these younger programmers who learned programming with Java, who had to write all that AbstractFactoryFactory "Enterprise Java" code, they see FP examples and think they have seen the light.
As the article almost admits, FP is basically a restricted subset of procedural programming. However, while these people were taught that "procedural programming" is an archaic evil and everything must be wrapped into classes by their Java schools, nobody told them that about FP (because the instructors probably did not even consider/know it). So now they can enjoy the simplicity and freedom of procedural code without the feeling of being "politically incorrect".
However, as I said, FP is simply unsuitable for most real world problems. The problematic thing about Haskell is not understanding monads, it's that they are necessary! They and other constructs like that are the "Singleton"s and "AbstractFactoryFactory"s of FP - what happens if you try to force something naturally "unfunctional" into a functional straightjacket.
The right solution is multi-paradigm programming. Use FP where it makes sense, don't use it where it doesn't.