I still use implicitly unwrapped optionals all the time, they're analogous to a precondition that a property needs to be set before usage, but cannot be set before self is initialized or has other DI oddities.
I can't seem to find the thread about "have a variable initially nil that can be set to a value, but it cannot be set to nil" that I thought was on here but that only aids with this usage, using a property wrapper/accessor macro.
That's not an option being discussed here. The alternative to implicitly unwrapped optionals is either explicitly unwrapped optionals or non-optionals. And the latter two are strictly superior in all cases where they're viable, which is most of the time.
As @nobody1707 notes, their primary purpose is for interoperability with Objective-C APIs and tools - particularly Interface Builder. Like goto they aren't strictly "evil", but they are easy to abuse and can too easily create more problems than they solve.
In a way IUO's are "superior" (or more capable) than the other two as they could do everything the other two could, plus more. For example you could take an arbitrary Swift app, change all "var x: T?" or "var x: T" to "var x: T!" and the app would still compile and run fine, while the opposite is not true.
If that's true and we could deprecate IUO's from Swift (so any usage of those would be a warning / error) allowing an explicit opt-out of warnings / errors (via a compiler option) for the legacy use cases like the mentioned.
Sure, like making your app crash. 
I think you mean to highlight the convenience of implicitly unwrapped optionals. Which is fine, although even then I'm inclined to say that it's a false convenience; that it looks good in the short term but creates a bigger problem long-term.
Anyway, this is all pretty tangential. Pertinent to the thread's original topic, I don't think implicitly unwrapped optionals are required for this pattern (of initialising a constant from inside a loop), as others have shown. And they certainly shouldn't be required for things like this - any impediments to that (like the compiler not understanding while true { … }) are unintentional and either just oversights, bugs, or unfortunate - and hopefully temporary - limitations in the compiler's smarts.
SwiftLint does that for you
https://realm.github.io/SwiftLint/implicitly_unwrapped_optional.html
Yeah, I mean something like that but built-in and enabled by default in some major Swift version (with the ability to out-out to compile old sources).
Would we add IUO feature today if we didn't have it already?