OOP has many inherent sources of accidental complexity that FP avoids.

1. Objects don't easily compose in the general, algebraic sense. Careful developers can create subsets of objects that compose, e.g. using the 'composite pattern' to model a GUI. For the most part, OO developers are stuck creating a lot of non-reusable glue between diverse object models.
2. Objects canonize one specific view of the domain by reification into stateful components and relationships between them. This makes it difficult to later take other views of the same system. Developers end up using horrible hacks like the 'observer pattern' when they need to extend an existing system with new views or maintain consistency between views.
3. Objects fundamentally favor eventful update patterns, e.g. in the form of method calls. These patterns inherently require a lot of state because developers must accumulate over events. Translations between diverse event models for object subsystems is very difficult, frequently requiring developers gather multiple events over time, recognize relevant changes in state, and redistribute events. A single lost, disordered, or invalid event can propagate bugs into the future, carried in object state or in-transit events. Developers are also pressured to choose between larger events for atomicity or performance vs. smaller ones for simplicity and modularity.
4. The abundant use of aliasing and internal state can make objects very contextual, difficult to test in isolation or reuse in a different context. 'Object capability model' languages such as E or Newspeak can help a lot, but most conventional OOP does not use such languages.

FP has a strong linguistic and cultural preference for algebraic composition at every layer (e.g. algebraic data types, functions, functors, categories, monads, machines, monoids, lenses, signal functions, algebraic effects). Purity makes it relatively easy to capture multiple views of a system, or to view an external state in many ways. Functions over data are a lot simpler than event patterns. Functions are relatively easy to test in isolation or reuse in a new context.

FP has its own challenges, of course. Due to lack of aliasing, squeezing performance out of a pure FP system is frequently more difficult. Integrating effects with external systems can sometimes be awkward. But I expect FP developers prefer FP's set of problems over OOP's.

Related:

[1] https://awelonblue.wordpress.com/2012/05/01/life-with-objects/
[2] https://awelonblue.wordpress.com/2012/07/01/why-not-events/
[3] https://awelonblue.wordpress.com/2012/10/21/local-state-is-poison/
[3] https://awelonblue.wordpress.com/2015/03/30/purely-functional-performance/