What I found in practice is that many people start using the ECS for speed, and then draw themselves into a corner of the design space. Now they have to weight every step on "how would it work in ECS?", and dedicate effort to fight the ECS paradigm.
For example, a mesh may contain multiple materials. Is each material chunk a separate entity? Or maybe each bone in a skeleton is a separate entity with its own "parent" and "transform" plus other component.
One of the different approaches is component graph systems [1]. It lacks the ability to mix and match components, but provides a more natural (and simpler) model to program for.
It seems to be good in theory, but I'm not really buying into any of the implementations of ECS, CGS or whatnot until they have a working, non-trivial example. If they have really thought it far enough, then they should have at least have a complex game as a solution to a general problem they are addressing. The demo in that repo you linked can be trivially implemented, CGS or no. Someone could rebut with: it's only a demonstration, but it's easy to scale any game of any size. In theory yes, but theory and practice aren't always friends. The actual complex game could serve as a proof, and the author can enumerate the pain points and limitations of the framework.
Wouldn't that take too long? Not really, just copy an actual released game, but using shitty (I mean, free) assets and make up some random content. It should cut the total development time from a week to a month at most. By copying, I mean everything, from the main menu, to in game-menu, to the little bits of logic that makes a game fun and engaging.
Since it generalizes ECS, I believe it should be possible to keep any ECS optimizations by having special empty components, in cases where those optimizations still apply.
For example, a mesh may contain multiple materials. Is each material chunk a separate entity? Or maybe each bone in a skeleton is a separate entity with its own "parent" and "transform" plus other component.
One of the different approaches is component graph systems [1]. It lacks the ability to mix and match components, but provides a more natural (and simpler) model to program for.
[1] https://github.com/kvark/froggy/wiki/Component-Graph-System