Yeah I would be wary of shoehorning 3 patterns into one thing.
I admit that there are a disadvantage with many patterns. They add some initial complexity and effort. This pays off when the application grows beyond some level of complexity. But if the application is small and simple enough, you need no patterns at all. Some patterns also takes effort to learn and understand. It is sometimes a good experience to implement something in the wrong way, to better appreciate the purpose of a pattern.
I am not sure what you mean by shoehorning. The ECS pattern and the observer pattern are orthogonal to each other. They are independent, and can each be implemented without disturbing the design of the other. So is the Model-View-Controller.
Especially the observer pattern seems to me like creating an entangled mess with looping back and forth messaging with at least the squared complexity of a traditional procedural spaghetti code, if any single thing in your program observes something and is observed itself by anything.
Events usually do not generate loops. Why would they? In the example I provided above, an event trigger a sound. The sound would not trigger another collision event. The message in the chat window does not generate another collision. Maybe I misunderstand, please explain with an example.
I would just try to follow the SOLID principles, never create any dependency cycles...
I absolutely agree. Using the SOLID principle, the collision system does not take responsibility for anything else but detecting collisions.
and just maybe use a single pattern if you are 100% sure it is truely helpful for the one problem at hand.
Again, I agree. But we don't know exactly what the requirements are of the OP. That is why I suggested some patterns that may help.