If you have a limited set of types, you can make extensive use of higher-level functions that compose frequently-needed operations on those types, and add your closures in the mix. If you have extensible types instead (OOP and such), you either have to program to these types, recreating the generic transformations for each type, or you'll need functions that can do those transformations on arbitrary types―presumably via internal mechanisms―thus circumventing strict type checking.

Or you need to be able to produce appropriately parameterized transformations on user-defined types without compromising safety, such as typeclass derivation?

I think the reason why it's relevant in this context is that returning nested trees of data is very much "open by default". If you imagine the equivalent situation in a typed OO language, and someone returns "ComplexContainerClass". It would be idiomatic in that language that the properties and fields of that class are not publically modifiable, so something that is doing the equivalent of "find a 3-nested member of this instance and modify it", is not relevant for two reasons: 1. The set on that field is probably private 2. It's a mutable change, so you don't need something like a lense to modify it in an immutable way. So the term "data-oriented" does make sense in my opinion, because you return and receive data, and have complete license to arbitrarily modify it at any level of nesting. Not that other languages don't have/use data, but not in as exposed a way. Maybe primitive-oriented would be a better name.