In ECS, one system can touch the innards of multiple kinds of components directly, and one kind of component can be touched by multiple systems. Components only hold data and no logic, so in most ECS designs systems will know about the internals of components intimately. This shows a design can ECS-compliant while violating a key part of OOP methodology: encapsulation.
You can use ECS and OOP in tandem by re-introducing encapsulation, as well as any other parts of OOP lost, but you need to be careful not to violate key parts of ECS, such as component not being allowed to have any “logic” (I out logic in quotes because it’s not well-defined: does logic mean ANY code or just... non-boilerplate code?)
One must consider how a codebase will evolve over time, which requires putting yourself in the shoes of those who will be working on the codebase. What benefits does strictly confirming to both ECS and OOP bring? Does the introduction of ECS bring enough structure that the codebase can remain clean, performant, maintainable, portable, etc even without OOP? Is there some kind of hybrid of ECS and OOP where the rules of each are relaxed to create an even better structure? How do all of these potential designs actually look in practice, and is there clear mappings from problems in the problem domain to the philosophical structure being imposed?
In games, it’s hard to map some of the problems to OOP structures (while remaining conformant, clean, performant, maintainable, portable). ECS isn’t perfect, but it’s much better.
I find using C-style, OOP, Actor model, and ECS structuring for different bits of code the best solution. There isn’t a one-size-fits-all when it comes to those things, unfortunately. Though I believe there will be one day (that is: a language arrives which has a model that everything maps to nicely and we’re all happy using and we all say “Wow everything’s so simple now”)