I'm +1 on this pitch, but think that this is a more general issue. Consider a type like Either:
enum Either<A, B> { case a(A), b(B) }
There isn't a significant structural difference between Optional and such a type — they're both generic enums that accept payload on their cases. Thus, an @noescape-type attribute for types whose payload is known not to escape seems generally useful. (I'm not sure if this is the feature described by @John_McCall or a feature that has been discussed elsewhere, so please let me know if that's the case.)
Admittedly, the sugar around optionals changes things. However, we could first introduce a general feature. This way, the implicit no-escape syntax of optional-wrapped function parameters would build on an existing feature, instead of being a niche Optional feature.