On most professional games I've worked on - just normal OOP, where you use composition instead of inheritance. Your components are based on this idea anyway, just without the fancy buzzword...
What I would like to know is what alternatives are there to ECS and how do they compare?
AKA terrible 90's "OOP" code
The most common non-ECS approach you're likely to find is the one that helped catalyze the adoption of a component-based approach to modelling entities in games in the first place: the deep class hierarchy, where everything inherits from some common base class and every time new functionality or behavior is required of an entity, a new subclass is created off of the most-similar existing class
The main idea of ECS - that you should always use composition to solve everything, is very similar to one of OO's core tennants - to prefer composition over inheritance.
From what I saw in the 90, people moved away from these horrible inheritance trees towards generic components because they wanted things to be more data-driven. C/C++ are static languages, but these teams wanted something more like SmallTalk, etc, so the implemented some data-driven aspect-oriented programming and messaging frameworks, which would allow game designers to create new 'classes' of game objects without requiring a programmer.
These days, ECS now seems to be popularised instead by the new wave of DOD interest - that this model won't necessarily be more data-driven and designer friendly, but the concern is that it will give better performance.
This new focus for ECS may itself be another reaction to OO architectures... Every console game that I've shipped on the most recent 2 generations of consoles has, instead of making the language dynamic via an ECS framework, has just used a dynamic language! e.g. Composition-based OO in Lua, which indeed is slow. This performance issues was managed by re-writing any performance critical parts (e.g. large loops over many objects) as multi-core C++ code (DoD and regular OO).