I'm not against exploring must-explicitly-consume types as a new language feature, but it's definitely out of scope for this proposal. Going beyond "Rust can't do it", I get the impression from conversations with Rust developers that Rust tried to do it, and rejected the results. Gankra had posted some helpful links about the history here in the pitch thread:
One of the points she makes is that ensuring something is explicitly consumed is a hard thing to prove through any level of abstraction or indirection. Even Optional<T> becomes difficult to work with, since you get pushed to explicitly consume the value even on paths you know it will always be nil. And that's in a language where static lifetime values are relatively pervasive; as you noted, for most Swift code, the norm will likely remain to work with copyable and shared-ownership objects, making static enforcement even harder to maintain. As soon as a value ends up owned by a class, an escaping closure, global variable, or any other shared-ownership location, then the only place it can be consumed is in that containing object's destructor, which could again run at any time in a context you don't control, defeating many of the proposed use cases.