I’m not sure it is; the heart of OOP is encapsulation of data + methods — the object itself. (Or message-passing if you’re being kinky)
ECS is almost the opposite; the object in question is barely defined — rather it’s derived from the composition of its parts. Like a DB, there’s roughly no encapsulation at all; just relations defined where, should you put them all together properly, you get the “object” back.
That is, in OO a particular object is composed of certain properties and capabilities. In ECS, if certain properties and capabilities exist, we call it a particular object.
Implementation-wise, the main difference seems to be the SoA vs AoS argument
But there’s also things like unity’s ECS deviating from rust’s ECS definition — I believe in Unity, components (data) and systems (behavior) are coupled, which fits better towards the OO world (components are the object of question). In rust ECS they’re decoupled (which unity is moving to, someday) and you’re really just dealing with structs and functions. And there’s a whole thing about the “true” ECS definition but it doesn’t really matter.
I've described an ECS to my friend as a combination Strategy pattern and Composition, so you can have a huge list of "traits/components/behaviours" and then build your object hierarchies (and their behaviours) from that, instead of from Inheritance. The way most game editors are made, when you configure things using the ECS, it visually looks like inheritance, but under the hood it is more like Composition. Once you go down the rabbit hole, you would see that and ECS/Strategy pattern & Composition makes more sense (and way easier to cater to exceptions) than plain old inheritance.
I want dare say that the enterprisey-version of an ECS would be the Onion Architecture that's been floating around in Java/C# camps. Not 100% match but they feel the same to me.
Obviously for normal GUI programming (at the outer layer that we see at least), inheritance is still king.
