The platform behavior already has "is touching wall" and "is on floor" which to my knowledge are handled in the behavior's script and simply return true or false -- using them in events does not create extra collision checks.
Actually as 
dop2000 has found, these both do collision checks internally as well. They are essentially glorified "is overlapping at offset" checks (but taking in to account other cases like slopes and jump-thrus).
But even before we get to that, the #1 question for anything related to performance - particularly when implementing new performance-related features - is: what measurements do you have indicating this is a performance bottleneck? The collision engine has already had tons of optimisation work done on it. In particular collision cells normally mean that objects only test collisions against nearby instances. Then objects whose bounding boxes don't overlap are extremely fast to reject as not overlapping. So the real work of collision checks tends to only be poly checks for objects that are actually overlapping. Even this tends to be very little work compared to everything else happening in a project.
The cases I've seen where collision checks really do affect a project's performance are truly extreme cases, like spawning 1000 objects on-screen at once and having them all check collisions against each other. In that case there's lots of objects in one collision cell, and so the main performance bottleneck is simply iterating through the ~1 million combinations of objects every tick. (And if that all got spread out over a large area, collision cells would still keep it running fast.)
It's easy to speculate about performance and end up spending ages writing lots of fancy code that ends up having negligible effect on any real games. As a small company with loads to do this has a high opportunity cost, so we have to be careful to spend our time on things that are provably necessary wherever possible.