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.
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.
I don't quite understand why the authors thought of this as a good example of "data driven design".
I know that functions in a data driven program tend to be very generic so the conclusion you cite is very much a mismatch from my experience.
The paper in question is this from 1989: https://dl.acm.org/doi/pdf/10.1145/74877.74885
It highlights that:
"Even though the goal of data-driven design is to encapsulate data and algorithms, it inherently violates that encapsulation by making the structure of an object part of the definition of the object. This in turn leads to the definition of operations that reflect that structure (because they were designed with the structure in mind). Attempts to change the structure of an object transparently are destined to fail because other classes rely on that structure. This is the antithesis of encapsulation."
Then goes to show that Responsibility-Driven Design has better approach.
What we mean with Data-Driven Design have come a long way though, and isn't comparable to those days.
I find it a bit amusing that Data-Driven Design used to be an insult of sorts, like you didn't know how to do things OOP the right way.