You make a good, general point. But I found that a data oriented approach has benefits outside of performance and resource usage, because it nudges you towards:
- normalized, small/tight data structures
- data structures that are closely related in computational terms
- smaller interfaces and functions that tend to be more re-usable and general
- fewer if/else branches and more existence based branching via loops
- fewer "business level" generics, macros and similar abstractions, because you can dispatch easily via tagging to concrete types
- less code that "digs"/"drills" into data and more code that composes data
- generally a simpler (less coupled) end result
This all comes with a cost of having to do upfront design and exploration in order to decompose and lay out your data. And while it reduces the mental overhead of understanding the individual pieces of your program on a day by day basis, it might increase learning curve of seeing the big picture, especially at the beginning. So it is a tradeoff.
But I think it would be too dismissive to say that the programmer is doing compiler work here. It is design work, and it is unlearning some of the notions of how to structure programs that carried on since the 90's. Some of which are performance related and some of which are about sensible code structure.