While I agree with your point, the map example is not entirely well represented in your comment.
The idea is not to just store keys and values in separate arrays, the idea is to look at your use case and model your data after the transformation you need.
So if you have a case where storing keys and values as pairs because of your access pattern, then do that, if you have a case where you do a lot of searches through keys, then store them in separate arrays.
The point of DoD is to look at the data you have and the data you need it transformed into and then structure your data after.
There are also multiple definitions of "data-driven" floating around depending on qualifier/context. An OLAP RDBMS, for example, will certainly be written in a data-oriented way, and also have almost fully data-driven behavior, but will certainly not have data-driven (in the sense of that paper) design.
Data oriented design is about structure the data in regard of how it is processed and the hardware. This is opposite of object oriented design which models the data around your mental model.
For example in DoD you would design a map with keys in one array together and one array of values. This would make it much faster to iterate over keys while searching because of cache memory.
While in object oriented you would store an array of pairs.
Both approaches can use data-driven.