I've seen some interesting Virtools projects where unfortunately the behavioural approach (like promoted by Virtools) is used too extensively with a huge number of objects and lots of scripts. If you have then a look at the profiler you see the behavioural manager is eating a lot of CPU power. Why?
I think it's ok to say that the behavioural manager is currently working a little bit like an interpreter because it needs to parse the graph of BuildingBlocks in order to check and manage the activity states of the linked components. The more deep and nested your graph is, the more it needs to traverse the graph – at least potentially. It depends on the activity states of the links and BuildingBlocks. That's also why you try to separate and wrap parts that are only active once in a while. A manager-like approach (one script handles many objects) might be a better approach for such situations.
Recently I started to read a little bit about (low-level?) continuations and (higher level?) coroutines , tasklets , micro-threads , generators. Some of this stuff was or is in stackless phython. There are some interesting articles in regards of implementing game object logic using concepts like tasklets. Maybe something like a behavioural engine could be implemented using either signals-and-slots or these tasklets and would then probally not suffer anymore from so heavy performance penalties when using lots of scripted objects at the same time. This concept of micro-threads is also used for EVE-online – a very complex MMOG. Some more interesting links:
Game Smart on Coroutines
Multithreaded Game Scripting with Stackless Python
Stackless Python: about Tasklets
Discussion Thread about stackless python, co-routines, micro-threads etc.
Gamasutra: Game Scripting in Python