> A) They aren't, they're probably already programming in a functional programming style.
This hasn't really been my experience. OOP in particular has a very specific design mindset, and I've seen that play out over several codebases. There isn't really anything I can call "functional" in a system fundamentally based on cyclic (often) graphs of mutable objects.
I think what may be implicit (and hence miscommunicated) in discussions about FP/OOP is that it's not about programming in the small (i.e. specific algorithms, blocks of code), it's about programming in the large (modules and their relationships; management of persistent data). Many examples I see of FP/OOP are algorithmic, and hence uninteresting -- you can get some nice ideas for how to condense your code or express the core ideas better, but it isn't exactly a paradigm shift.
Every Turing-complete language can encode any computable function; algorithms may have complexity distinctions but are ultimately not far removed. The FP/OOP discussion would be better served discussing the architectural implications of these styles.
> B) A lot of FP articles come off as the musings of zealots obsessed with monads, which often barely make any sense to, well, anyone.
Monads are an example of a dominant architectural pattern in FP that takes advantage of the core conceit of the paradigm. I think monads tend to be explained at the algorithmic level, which is unfortunate -- in many ways, they're about decoupling domain logic from control logic, which (I will posit) is desirable in any system, not just one that's FP.