All the games you are referring to didn't target increasingly parallel hardware. ECS is made to scale in ways OOP will not be able to.

Plenty of successful software, including the currently most popular game engines, are designed with strict OOP principles. That doesn't mean there aren't well-documented flaws with it as behavioral complexity increases.

I'll wager that if O3DE sees an actual release with real documentation, it will herald a new generation of ambitiously-scoped games that actually realize their ambitions instead of crumbling under OOP-induced technical debt.

There are a couple of reasons; performance is one.

Besides that, games have an (un)surpring level of coupling between entities. Even a simple, few hundred lines game, is a tangle. The ECS designs decouples the entities, which is a very significant design improvement.

What has been done in the past is not really indicative, as ECS is relatively new (in the grand scheme of things).

Something that can be said though, is that ECS is frequently considered overkill for small projects.

I can assure you, lots of "classic EC architecture and even OOP architecture" games also have many Systems in the ECS vein, when they need them. Not for the performance (that's tied to memory layout in ECS) but when it's easier to implement a given piece of logic that way. Traffic, pedestrians, opponent AI, weather, mission flow, encounters, are a few typical examples.

I thought gameplay and game design was what mattered most, not everyone is trying to beat Fortnite, FarCry,....

I think one doesn't need to reach that complexity in order to benefit from ECS design.

On the other hand, most of the games have somewhat-throwaway code, so the code design may not be so important indeed (VVVVVV was for example discussed on HN).