you should "destroy" once you've determined the "fireball" actually interacts with a "killing wall" - which presumably happens in preCollision (because the one-way logic can't happen anywhere else - go ahead and try it if you like, but eventually you'll return to preCollision.event.contact.isEnabled)
iow, there's no point in "deferring" the destruction until postCollision (fe, set a "flag" in preCollision, then destroy in postCollision)
caveat: this is assuming i've correctly understood your setup, and you need the fireball to "pass through" the first wall (ie, ignore the first collision) and then be destroyed by the second (btw, at which point the contact with the first wall would still exist, unless moving fast enough to tunnel through it in non-continuous mode)
>> In your example, the preCollision check will not prevent the call to the collision event
of course it doesn't, as this NEVER happens. you CANNOT "prevent" the call to the collision event. all you can do is prevent the response. "collision" happens (necessarily) before "preCollision". as i said before: stop thinking in terms of Corona's event *names*, because they'll only confuse you if you do -- "preCollision" can only happen AFTER "collision".
maybe it helps to consider what a sensor is: a sensor detects contacts, but never issues a solve. THAT is what the preCollision.event.contact.isEnabled=false mimics when doing one-way platforms, it says "skip the response". but note that the contact itself still occurs regardless!
>> Its noisy
"noisy" is a relative term. the preCollision/postCollision events (aka "solve" events) fire more often (ie, per frame) because they are not persistent like the less-noisy collision event (aka "contact" event). so while you'll only get one contact while moving through a wall, you'll get many solves (one pair per frame, for as many frames as it takes to get through, depending on relative velocity vs size of objects).