Well, it does work well for the engine part of game engines, and graphics related code in particular as the GP says - it's just gameplay code where OO falls a bit flat.
Not really, the data oriented design movement in games programming that eschews OOP is driven by performance concerns of traditional OOP code on areas like rendering.
As a graphics programmer for many years I can also say that OOP is not really a good fit design wise for modern rendering engines, it mostly just gets in the way.
I only really know of Bevy that uses ECS for the rendering backend, but iirc even that doesn't really use entities and components, but rather its resource system, such that rendering commands are stored in the ECS "world" but as globally unique resources, rather than entities and components. But, my knowledge doesn't extend to AAA engines, perhaps things are done more extensively there.
I don't follow - role playing games are often most suited to ECS, because you want the kind of emergent gameplay that independent gameplay systems acting on component composition gives you - and the kind of flexibility it allows in composing weapons, spells, buffs/debuffs, and so on, vs a strictly hierarchical OOP approach.
