I'm in favor of default style conventions and a formatting tool to enforce them, including whatever degree of configurability would meet that goal.
In the pitch thread, I compared this to the automatic formatting provided for manuscripts and screenplays by word processors. Those tools exist so that writers and readers rely on the same visual cues to scan content. In my opinion, consistency is more important than personal style, especially in today's globally connected environment. Just as the focus in a manuscript should be on the content, the focus in a source file should be on the logic. I'm sure teachers, for example, would appreciate the reduction in the degree of "creative expression" in code formatted by new programmers.
One counterargument is that the official establishment of a default style would eliminate preferred styles or tools, but that's addressed by the fact the tool will be optional. If you don't want to use it, don't. Or configure it, if that addresses the concern. Or use an alternate tool.
A related counterargument is the social angle: the fact there will be a default style and an included formatter will most likely establish an official canonical style in the minds of most. But, of course, the point of a default style is to be widespread. Otherwise, the goal of consistency is unachievable. Therefore, the style must necessarily be perceived as "vanilla Swift," and this is a good thing.
Users already answer style decisions by copying Apple's sample code and WWDC presentations, along with whatever formatting inconsistencies are included in them (hopefully to be addressed by this formatting tool as well). Much of Swift's style comes from what we saw from Apple when Swift came out, the rest deriving from whatever common Objective-C conventions translated well. The rest is full of esoteric details, the sorts of details a formatting tool will eliminate arguments over. After the subsequent community debates decide them, anyway.
Which leads to my final point about impending community debates if this proposal is, as I hope, accepted. The potentially extensive debates over the conventions and best practices to enforce will be a good thing. Let the energy be expended and the arguments be made so that users don't have to. Compare styles, relate experiences, and attempt to determine which visual cues serve best in most cases. It will be especially interesting to hear from maintainers of large projects like swift-corelibs-foundation.