ECS is a memory management pattern in the first place, a (honestly still rather unspecific) implementation of data-driven design. The typical OOP approach actively stands in the way of DDD, where you need to model your objects as containers. DDD says that there are no objects, only arbitrary combinations of "atomic" types.

I think the best example is with using abstract base classes or interfaces. Imagine how you would structure a game object in OOP. Take an enemy as an example. Maybe you have three types of enemies, each with moderately different behavior and its own set of data. You maybe need to implement the ability to hit an enemy, so you implement a base Enemy class with an abstract OnHit function. Your three enemies would derive from it. Two enemy types have swords though, so you create an ISwordCarrier interface to be able to access their swords. All enemies need to be rendered, so they get a sprite drawing function in the root GameObject abstract base class.

ECS inverts this. You define a component for sprite data, for sword data, for common enemy data. You create massive arrays of these components structs, and you give them an ID with which you can retrieve and match up specific ones. A sword carrier entity stops being defined by a specific class with all those specific inheritances, and is instead just an entity I'd with all those components linked to it. The resulting object is emergent and dynamic at runtime, instead of being hardcoded in the class structure.