The problem in my opinion is that many game-engines are to focused on the "PerFrame view of the world" statically imagined by the designer and do not architectu

The problem in my opinion is that many game-engines are to focused on the "PerFrame view of the world" statically imagined by the designer and do not architecture for persitent but changing effects or long causal chains that constantly change and are capable of reusing behaviour. Good news though is that most by now, outsource that to scripting languages capable of providing better ways to implement this, but then you end up with parallel implementation of basic behaviour & services like pathfinding or targetting. Imagine a late-game added lightspell, that is expected to behave like a ball lightning walking ahead of the player. The temptation to reuse the pathfinding, collission and other systems that controll figures will be enormous. But this behaviour needs a sort of CBipedal class to inherit all the behaviours. Voila - enter the hack. Of course the clean solution would be something like a thrown stone on a lake, it exists as running code only when it changes (certain frames or events). It holds a composition of behaviours without the other ballast (datastructuress for aiming, inventory) etc. and also does not need a pool allocation to the monster/npc pool. (Basically you either have many peasants or many lightballs in the hypothetical as tradeoff). Cause it aint a object, its a entity with a collection of behaviours, with a minimal data container bound to each behaviour seperatly, that may evaporate at a moments notice, should the player look away or its time run out.