I'm not sure if this will help, but I can share a little of my own experience with optimizing, via the use of "every-x-seconds conditions".
If there is a lot of collision checking going on in a single event, and you can get away with doing it less often than every tick, that's the main place I've actually seen directly visible performance gains.
Though I suspect that pretty much any non-tick-essential event, if it's already eating up a large share of your game's CPU budget, is a good candidate for demotion from per-tick to every-x-seconds.
As a practical example, in ArcherOpterix, the phantoms check to see if they are touching a wall, so they can reverse direction. That check uses an "overlapping at offset" condition. The phantoms move slowly, so I didn't really need it running absolutely every tick. I switched it from every tick to every 0.2 seconds, so the phantoms behaved identically to the naked eye, but the game ran about 2 to 3 times faster.
Now that said, I'm not sure why I wasn't then just getting a minor slowdown every 0.2 seconds. But I didn't. The game ran smoothly. I thought it was a bit weird, since my game should still be running all of the collision checks on a single tick every so often, and in-between there would be a bunch of far less demanding ticks.
So if the work load isn't being spread over multiple frames automatically, and I don't think it is, at least not at the C2-event level, then maybe there's some hapless downstream system that gets backed up if you just pile tons of work onto it, until you start to see that burden manifest as a performance hit.
In hindsight, I could have given each phantom a random group number from 1 to 10, and then just handled one group per tick, round-robin style, to spread out the work load a little. Though the every 0.2 seconds optimization worked so I've left it with that.