As before, I feel like you're still conflating what I'm talking about with CES and object composition in general. I expect some non-commenting readers probably do, as well, so I'm going to clarify: it's not CES, and it's not "composition" in the sense that is usually meant. There are crucial differences here.

It's not that I'm conflating it, it's that I'm talking about the general case of moving towards composition-heavy frameworks.

Unity / Unreal components are very primitive, as they're just crude sub-objects. There you get some of the benefits of better coherence with all the downsides of multiple permutations, ordering issues, having to check for presence or absence, etc. Unreal throws in a deep inheritance tree as well so you get the worst of both worlds. But, it is at least a flexible and well-understood system. They took the massive Actor/Entity/GameObject class and provided tools to compartmentalise them a bit, which is a useful step.

A 'pure' ECS, as a lot of people like to talk about, does all the logic in the systems, treats components as data, and entities are just a key that associates several pieces of data together. This is cleaner in many ways, at the price of making it hard to get the system to do anything useful without introducing complexity. Systems that start off only requiring one component start requiring several to work in tandem. People consider adding message-passing or signals/slots to try and get some sort of communication. They invent contrived systems to enforce component dependency where component A requires B but can't sensibly be merged because system C doesn't require anything from A, just B. Good games have been shipped with this system - System Shock 2 and Thief, and Dungeon Siege - but the Dungeon Siege approach was described by the author as a "complex system [...] more prone to spaghetti because components very often need to talk to each other".

What you talk about is arguably a step further, doing existence-based processing on objects that can represent, as you say, messages, or tokens. I would argue this is too abstract for most people to be able to make any practical use of, and that is complexity in itself, no matter how elegant the eventual solution. When most people talk about components or composition they're not talking about a system like yours - because most of them (including me) would have no idea how to make one or be productive using it.

Kylotan, I think this is a good summary.

I recently took a step back and in my opinion this all comes down to the problem of reusable software. From my experience smaller systems are easier to reuse than larger ones. Working in a large codebase on a daily basis I also found that it is usually very easy to work on the low end system (e.g. a material system, collision, or physics) and all the way on the other end when implementing some behavior for some entity. The real complexity is in the glue part in the middle that brings both of these ends together and this is usually what is called the engine. In order to make the engine reusable we now come up with meaningless abstractions like entity, component and system. We choose a component decomposition without any context and end up with a small granularity to potentially meet them all. I am wondering if it all boils down to ditching engines all together and write games instead. For reusability we now have nice game specific modules (e.g. material and rendering, collision and physics and pathfinding, etc) and potentially discover more along the way. On the downside for new projects you will need programmers to setup a minimal tool framework for artists to start. If you only have content people that will definitely not work.