I wouldn't necessarily agree with this. Many functional programmers actually prefer some of the advantages of black boxes. Even methods as a calling interface vs functions are more a stylistic difference (when you aren't factoring in subtype polymorphism). OO languages tend to have the convention of not keeping effectful operations in methods referentially transparent (with effectful values), but there's nothing inherent to the idea of OO that says this must be the case. Scala could just as easily have something like haskell's IORefs instead of vars and make use of an IO monad to achieve a similar effect.

I'd argue the bigger difference between the two styles is with methods of polymorphism, but even functional programmers in different camps probably don't agree on the reasons for why they prefer not to have subtype polymorphism.

Your opinions about encapsulation probably have more to do with your preferences wrt typing discipline. Functional programmers who prefer static types often view black boxes as an asset. In fact black boxes form the basis of the free theorems, which can provide some nice assurances about the behavior of code that has few assumptions about the data it receives: https://bartoszmilewski.com/2014/09/22/parametricity-money-f...

Similarly, data without exposed constructors can be used to enforce strong invariants about code using techniques like smart constructors: https://wiki.haskell.org/Smart_constructors

Black boxed data also conveys advantages for library maintainers. It makes it much easier to change implementation details, because you're only required to preserve the semantics of functions operating over data rather than its exact innards. Not doing this for the String data type in haskell is arguably the largest reason why it won't be phased out to the superior Text type: http://dev.stephendiehl.com/hask/#string