Madster: that's correct, if you use a condition to filter down the objects before checking an overlap, then the overlap is only checked on those instances matching the previous condition. (That's the normal operation of conditions - filtering down instances condition by condition.)
The fact invisible offscreen sprites still affect performance is for two reasons:
1) If they're animated, the animation still needs to be ticked along so when they come back they're showing the correct frame. If they only have one animation with one frame, though, I think an optimisation kicks in that does no processing at all, though.
2) Construct must check every renderable object every tick to see if it needs to be drawn. Even invisible sprites are checked - it will just say, "oh, this one's invisible, next please". If it is visible, it does a very simple is-on-screen check (determine the bounding box then one to four integer comparisons) and if it's not on-screen it skips to the next one as well. These are trivial and take a tiny amount of time on modern processors, but with hundreds of thousands of objects these tiny tests become significant. 100,000 objects at 60 frames per second is 6,000,000 checks a second.
If you like calculations, since that's running on a single core at probably around 2.5GHz, each sprite takes about 400 cycles to check, which is about 160 nanoseconds. Yep, most games probably don't have to worry about that!
It's possible to improve the engine such that invisible or offscreen objects don't even need to be checked like that - it's something I'll consider for Construct 2.