Absolutely. My intent with the word "official" is the definition "having the approval or authorization of an authority or public body". In this situation, "authority" == the Swift Core Team. That is simply meant to convey that the Swift team is giving that particular set of style guidelines their blessing as an example of what they think is optimally readable Swift code, is one which they would ideally adopt across the various Swift projects (corelibs and others), and which they would be happy with being the "default" style for an adopted formatting tool without any other configuration, since there must be some default behavior. Clearly these matters are subjective and pleasing everybody is a non-goal because it's impossible, but that doesn't mean we can't make any progress in the area.
The implication of the word "official" is that any other style guidelines outside of those would be "unofficial". That doesn't mean they're bad or incorrect, nor does it imply that attempts to use a different style would be met with enforcement or restriction of any kind. Perhaps there is a concern that anyone who wishes to use a different style than the hypothetical "official" one or presents such code in a forum would be met with derision? If that were the case, that would be a personal intolerance problem, not a style guide or tool problem, and it's something that should obviously not be allowed to happen. People should feel free to use whatever style they wish if they're not contributing to a project that has specific guidelines.
I'll make this more explicit in the proposal text before it goes to review since it's been a point of contention or confusion.
To some degree, yes. I do consider the comparison to the API Design Guidelines to be apt, because we're trying to achieve a similar goal on a different axis of the development workflow. The Swift project recommends API design guidelines that are "official" in the sense that they are blessed by the Swift team and hosted on swift.org, but they are not required to be followed nor does the compiler try to force users into them. In a personal project, people can design APIs however they wish, but in team environments or other collaborative situations, having a common agreed-upon set of guidelines improves communication and understanding. It also makes it easier to transition from project to project, if those other projects follow the same guidelines. In fact, if it were more tractable to create a tool that could apply grammatical analysis to APIs to an accurate enough degree that it could correctly diagnose and suggest corrections for names and signatures, I'd personally be very excited to have that and would embrace it.
The same argument can be made for code style. I'm not 100% sure "idiomatic" is the word I would use here because I think that holds more weight in the API Design Guidelines case than it does for code formatting, but I can't think of a better one off the top of my head. Regardless, the underlying motivations are the same: to smooth out and improve communication, optimize transferability of skills, reduce barriers to entry for newcomers, and remove less important issues from consideration so developers can focus on more productive matters.
Some community members have strong preferences about personal style, and that's fine. Nobody can, will, or should stop them from doing whatever they wish. But for the many above who have said they would embrace a unified set of guidelines that the Swift team feels capture the notion of "ideal Swift code, stylistically" and a tool to make applying that effortless, this work is for them. Developers naturally look to the language owners to provide guidance and best practices, and having guidelines that are blessed by the Swift team—especially if the core projects themselves adopt them—will be incredibly useful for communication and education.