Composition based OOP ( where it makes sense) is great and can see it being used locally ( sub-component level ). Or any other piece of hot-code where you really need to optimize after the system is designed and approved. Losing the abstraction layer of components, for example, seems a bit heavy-handed to me. Would be hard pressed to see our hundreds of components done this way. It could be done, I'm sure, but at what cost to development/ maintenance time? The example as far as I understand it ( based on this tiny snippet ) has a similar problem to unity's ECS framework. It requires an upfront, close-to-complete, system design and is rather inflexible in nature. Any more than a trivial gameplay change requires a programmer and at least one recompile.
Does it not create a host of other complications like designer-specified data, toolset integration, regular inheritance use-cases like automatic script bindings, etc ? One of our major risks is iteration speed and it's only very rarely programming iteration speed ( at least in the mobile world ). Granted, on more constrained platforms with fiercer competition ( to be read as the graphics race ) I can see this as being an affordable compromise