IIRC from looking into this in the past, i think there is a runtime check/assert of the refcount of the closure argument at exit of the withoutActuallyEscaping function, so i would guess that's the point at which you'd generally expect to see a runtime error (though with optimizations on, idk maybe it moves around or isn't 100% reliable).
as i understand it, it's just a tradeoff. in your initial example, the compiler's analysis is conservative and it won't let you express in-actuality-safe code. rather than that just being the end of the story, Swift gives you an out, but it's a 'Spider Man' sort of deal – you take on the responsibility of ensuring things don't escape (well, the runtime tries to 'help' you too, by crashing if you've failed to uphold your end of the bargain).
i would expect as the ownership model and stuff like ~Escapable types becomes more fully built-out, we will get more precise control over this sort of thing. e.g. if you could just declare that your local variable is ~Escapable in some manner, then i think your initial example would work as desired without need for 'opting out' of the static safety checks. mabye this is possible today and i'm just unaware of the syntax you'd need to do it? sounds like an somewhat entertaining exercise for the reader 