I'm no expert, but here are my 2cents.

One of my "ahhh moments" with ECS was when someone pointed out. The ECS has a very 'strict' boundary on DATA(attributes,entities,components) VS BEHAVIOR (methods,systems,functions).

The 'traditional OOP' usually 'smash/hide/design/encapsulate' these two conflicting powers into one 'Entity'

I think it's 'easier' to write a ball-of-mud in OOP for games, then it is to write ball-of-mud with ECS.

*NOTICE I said 'easier' not 'impossible'

I love the distinctions between BEHAVIOR and DATA, from an organizational point of view. The bigger the whole system is the more value I think a good programmer can get with ECS.

Imagine having to "implement" gravity for 100 different types of 'Objects'. Sure The ECS way would be to have a System(Gravity) that executes the 'same computing' on all entities with a 'MassComponents' and 'PosComponents' for example. The Entity would usually not need to know ANYTHING about Gravity. Sure the OOP way one can inherit but eventually you inherit yourself into a corner (diamond-problem).

My 2cents - YMMY

TL;DR (just squint hard enough)

ECS ~= (Data | Behavior)

OOP ~ (Data + Behavior)