I'd love to see an example where an use of it has made the code more readable and easier to maintain by the way

I don't have any specific example for you at this time, but I will point you to some people who can expound on that subject. There's the points raised in http://www.dataorienteddesign.com/dodmain/, and the ones Mike Acton raises in his CppCon talk and "typical C++ bullshit" slides. I'll summarize what I took from both of those:

• having your data declared in a simple, straightforward way instead of hiding it behind layers and layers of encapsulation and abstraction makes it easier to reason about what state the program has and what subsystem owns it - and I'd add that in a more data-oriented programming style, you might segregate your data by how often it is mutated, which can make it easier to understand where state changes happen
• implementing functionality by composing transforms of collections of data allows you to more quickly find where a bug is actually happening because your state mutations occur in specific places meaning that you can quickly find where a corner case was missed or where an unintended side effect is happening
• existence-based processing can cut down on the cyclomatic complexity of the code by reducing the number of checks for validity you need to do - and in my experience, checks for validity (ie. null pointers and such) negatively affect code readability in a huge way
• concurrency becomes easier to implement and debug when you build your program by transforming sets of homogeneous data instead of structuring your program around transforming individual pieces of data in isolation

To me, the essence of being "readable" means that I can understand what a program is trying to accomplish and how it goes about accomplishing that with a minimum of effort. A program that is "easy to maintain" is one that is easy to debug and easy to change in such a way that I don't introduce new bugs in the process. My impression of data-oriented design is that while it might appear that these data-oriented systems take more effort to change, I think ultimately how long it takes me to make a change is more important than how much code I need to touch. Those two things are related - "effort" here means the time to make the change plus the time to debug it - but given the choice between making a larger number of small changes that I have high confidence won't break anything and a smaller number of changes that are more likely to break something elsewhere in ways that I need to think extra hard about (eg. if I fix a bug in a base class that breaks subclasses), I'll take the former.

My experience with my own code (which I've recently started writing in a more data-oriented way even for gameplay code) is that I tend to add new features by adding new subsystems instead of modifying big swathes of existing code to add the features to all the different classes that already exist as tends to happen with the (object-oriented) projects I've worked on and still work on at work. Most of the true object-orientation in my own code occurs at the feature subsystem level, not at the individual data object level. This not only means that it's easier to fix bugs in specific features (because the code and data for those features is all in the same place), but my confidence in the correctness of the existing codebase gets continually higher as I add new things. I already spent time to make it work, and I'm not changing it, after all.

It might be interesting to take a reasonably complex program and implement it in "typical OOP" and "typical DOD" and compare the two to see how easy it is to do different maintenance and implementation tasks in each system.

edit: And I think it's a misconception that data-oriented programming = focus on cache performance and avoiding branching. Those are things that can come out of taking a data-oriented approach, but I don't think you need to go all the way to using bitmasks instead of conditional branching for your code to be "data-oriented". Data orientation to me just implies that your code is built around how your data is laid out and your data is laid out according to what you actually need to accomplish instead of trying to model the "real world" with abstractions in code.

As a note, many paradigms are compatible with each other and work well together. Others are located on a continuum.

I already mentioned several earlier in the discussion. Object oriented works well with event oriented paradigms. Object oriented works well with state machines and automata. Object oriented is on a continuum with functional development, one preferring verbs the other preferring nouns.

Many people interpret "object oriented" as inheritance trees or deeply nested commands. While it is true that some systems do this, that is not what object oriented is about.

Object oriented is part of the continuum of preferring nouns or verbs. Languages tend to prefer objects, the nouns, or they tend to prefer verbs, the functions or actions. When you crate an opaque structure and operate on it like C's FILE*, that is a noun. When you work the opposite direction, SELECT whatever FROM whatever WHERE whatever, you are focusing on verbs, that is more functional.

Object oriented and data oriented can be orthogonal. You can have both, you can have either one, you can have neither. I can create an object that is composed of SoA or composed of AoS, both are still treated as a composed object that represents a bunch of items in a collection.

Edit: It looks from doing some reading like some people are treating 'data oriented' in the same bucket as 'functional'. If that is your interpretation of the term, and since there are no official definitions, then yes, they are both on the same continuum. But please don't use it that way, there is already a name for code that focuses on the manipulation of data as verbs through functions, it is called functional programming.

Object oriented is part of the continuum of preferring nouns or verbs. Languages tend to prefer objects, the nouns, or they tend to prefer verbs, the functions or actions. When you crate an opaque structure and operate on it like C's FILE*, that is a noun. When you work the opposite direction, SELECT whatever FROM whatever WHERE whatever, you are focusing on verbs, that is more functional.

I find that when making games I love using OOP. Games just have so many objects that could be in the real world and it makes sense to me. When I write business applications I have a hard time using OOP because I find it harder to break concepts into objects that mean something to me. OOP in my mind just works better with actual objects you could touch and see vs concepts. A player, a coin, a bad guy, these are all very much physical things.

OOP, DOD, procedural programming and whatnot all have their place in software engineering. I have a lot of trouble with programmers who pick one winner and then blindly apply it even when it is not appropriate. Personally, I love the C# programming language and I think it's the best designed language I have programmed with and that Anders Hejlsberg is a genius, but I wouldn't use it for absolutely everything because neither C# or pure OOP are not suited for everything. I used to code pure OOP, but doing system and driver programming on Linux in a OS class at university made me appreciate the C programming language. One of the great things about it is that I can look at C code and have a very good idea what the compiler will do with it because machine code is like that. OOP languages like C++ tend to hide things for you. For example, a function may look very simple and only a few lines of code, but then you look at the assembly and you see 5 virtual destructor calls, with each one doing a system call to close OS handles. In C there's no surprises like that, but on the other hand you have to do it yourself or you'll leak resources, so you can't be lazy. Personally, I believe in a balanced and context-sensitive approach to software engineering, not absolutes. I use the right tool for the job.

I enjoy "playing" with memory layout and I have fun trying to optimize its usage to avoid cache misses in a C/C++ application and squeeze as much performance as I can, so data-oriented design is an interesting concept for me, but I also like exposing APIs as a clean package of C++ classes because it (at least to me) feels more familiar, more structured and easier to maintain, so again I think balance is important. When I'm coding close to my engine I'm going to be paranoid about cache misses and might mangle my OO design a bit in the process if I realize something wastes more time than I expected, but when I'm writing code that only runs sporadically, I'll prefer a clean object-oriented design.

Somewhat related, but there seems to be some hate for the C++ programming language in the FSF community so I wonder if this thread was created after the original poster read something about OOP from a FSF guru. Linus Torvalds, for example, has a profound distaste for C++, and said he would even refuse to work with a C++ programmer. Now, Torvalds is pretty much the paragon of those anti-social hackers who know everything about a CPU but can't say 2 sentences in a row without insulting somebody, but if system/kernel programming was all I did, I doubt I'd find C++ very useful either since too many of the language's facilities are either off-topic or not very useful in kernel mode. Also, the GNU coding standard (assuming anyone calls that a coding standard ) says that you CAN use C++, but you basically can't do anything interesting with templates. (But this is the same "coding standards" that forbids using the term "WIN32" if you port to Windows because RMS doesn't want you to abbreviate Windows with WIN...)