You raise a great point, and I actually agree with Richard's conclusion. DOD is a collection of "tools". I think though that ECS goes beyond that.

The problem is that the perceived complexity of ECS is different from the actual complexity. The most basic definition of ECS is appealing, with just three concepts that are easy to understand and are powerful. The perceived complexity of ECS is low.

Where the challenges arise is that those three concepts (entities, components, systems) touch upon everything that is important in executing logic in a game, which are entity organization, data storage and system execution. That is where things get hairy.

Imagine taking the approach of "ECS is good enough as is, and doesn't need anything else". An example of a challenge you will run into is, "how to do hierarchies?". There are no "native" constructs for it, so I either have to build it external to ECS, or design it in ECS with custom components.

Either approach would increase complexity of the usage of ECS. Additionally, making decisions itself about what to do in ECS and what not to increase the complexity of usage, since there are no clear cut answers.

This problem does not just come up with hierarchies. System ordering, generalizing of behavior, implementing state machines, level switching, asset modeling, asynchronous loading etc. are all problems that many games will have to address, and for which no clear answers exists in the vanilla definition of ECS.

That leaves us with a choice: either to leave ECS as it is and let projects deal with the incurred actual complexity, or enhance ECS by adding more primitives and increase its perceived complexity. The reason why I wrote this blog is because I opt for the latter.