OOP in game development is in good use with engines like UE4 and Godot, so it is about choice. What really matters is how comfortable you are with the way you develop the game.
Oddly enough I've been getting into UE4 and things would be so much easier for me if the core classes were better decoupled.
For instance, I'd like to have a quadraped skeleton with the ability to apply a movement vector. Unfortunately, in the Actor->Pawn->Character hierarchy, you cannot have movement (applying vectors, walk/jump/fall state) without a capsule root component - which is the only one respected for collision - so either I have to rewrite all of the movement code or somehow make the capsule vestigial and carefully maintain its state.
In short, in some cases it's useful to say that a Pawn is an Actor with a set of extra features, or that a Character is a Pawn with a set of extra features, but even there, the way inheritance forces you to adapt an exact set of extra features and no others and also those features are not piecewise reusable elsewhere is a pretty big structural problem.
I've already done enough arguing about OOP for one career in programming, I think, but the more I see what's out there, the more that I think the real enemy is any use of class inheritance - even the TAPL formalization of OOP uses interfaces only.
I certainly agree, I ever used ECS from the beginning. Just surprised when I saw a new engine like godot follows OOP. It might be because engines are better fit but not the game itself and gets omitted easily.
I don't get it when a functional programming comment gets highest score in a game programming pattern thread while a game-dev related view gets the lowest.
