This gets brought up a lot. Data orientation was a term coined in two different programming communities: game engines and information systems. The terms have overlap and some of the implications are similar. But there are also significant differences as the game programming term focuses on data layout and performance, while the information system term is more about simplicity and leverage. They both are divergences specifically from mainstream OOP.
The game programming flavour of data-oriented design is often described as an optimisation technique, but I feel this is a misconception. Performance and maintainability are not mutually exclusive.
My understanding based on talks by Mike Acton and others is that DOD is biased against adding unnecessary abstraction, which in turn makes it easy to understand (i.e., maintain) the software. If you can reason about what your program is doing - which bytes are read and which are written, adding things on top might be unnecessary and hurt readability. You don't necessarily need to care about optimising for cache hits or data alignment; if your software needs to 1. read a "name" from the network, 2. make sure it's lowercase and 3. write it to the database, then just do that. There's no need to have a "name" object with constructors, getters and setters; there's no need to split your functionality into 1000 "reusable" little modules. The only time you'd use a class is when it helps prevent resource leak, so you'd use RAII when opening files in C++ to make sure they close when leaving the scope.
