The problem for me in regards to OOP is the complexity related to the management of state. OOP encourages mutability and understanding the state of an object as its methods are called can be confusing when additional internal (and often times, private) methods are called. In functional programming, state is something acted upon by functions. It is as simple as f(x) = y. Reasoning in functional programming is much clo…
Maybe the "impedance mismatch" between pure-fp and I/O is too great, with the IO monad being the "leaky abstraction" of the FP world.
Then OO is not a bad solution to an irrelevant problem, but a pretty-good solution to a bad relevant problem.
EDIT:
To clarify: The "problem" is change.
Imperative programming relates sequential device-change over time, to sequential programming lines. OO programming is a structured imperative programming.
Pure FP langs model sequential change with (roughly,) lists of actions to-be-performed that are snaked through your program.
(Also: maybe OO's failure has more to do with its limited static analysis, type systems, than its model of change?)