To Elaborate on some of @clayellis's points, it seems relevant to bring up some of the purpose of Optionals.
This is obviously not new information, but one purpose is giving users a way to easily guarantee runtime safety at compile time. It requires being explicit about whether a value is required or can have no value. If something is declared as Optional, having no value is a valid state and has a very specific runtime meaning.
So if this seems like a special case, that's because it is. Things like empty Arrays or Strings have no specific meaning to the compiler or runtime. .nonedoes.
One thing that hasn't really been brought up is the amount of flexibility and brevity implicit .none gives. E.g. subclasses not having to initialized as many properties in their custom initializers.
Previous domains should also probably be mentioned. Class @propertys in Objective-C are implicitly nil, so having similar behavior in Swift helps with knowledge transfer, as well as converting/interfacing-with existing legacy code.
It’s ok to both like and prefer the current implementation, but to call it useless is factually incorrect. Explicit initialization can prevent real bugs, and there is a real semantic difference between uninitialized and nil. There are real, measurable use cases.
Please refrain from stating opinions as fact.
What you mean to say, is that you don’t care much about that difference and that the convenience of implicit initialization far outweighs the costs. Which is a fine position to have. But it doesn’t make the suggested change “useless”.
To be honest, I don't have a single opinion here. If you were to default initialize a value, nil is the most appropriate concept to use. I could even see a case for this to be expanded to encompass all types supporting ExpressibleByNilLiteral, rather than being tied to the ? and ! shortcuts for Optionals.
I do think a rule change around properties needs to take into account lazy properties and property wrappers, both of which also change the perceived behavior of initialization.
I can see a case for requiring explicit nil for (?) Optionals. For (!) IUOs it would seem very counter intuitive to have to explicitly set them to nil at init time since their semantic purpose is deferred initialization.