I don’t think anyone is arguing for this. The default style would in fact be very opinionated. I suspect most of us would prefer to stick close to this default style, but there will inevitably be some decisions it makes that we don’t want to be pinned down on. The specific decisions and rationale for wanting to deviate from the default will vary from project to project.
The existing open source ecosystem provides some excellent tools. However, it cannot and will not ever set a baseline in the form of a default style that is shared by the entire community. Further, the defaults that do exist in these tools have been chosen by their authors rather than discussed and reviewed here on SE.
Aside from defaults, I also believe there is merit in having a standard tool that ships with Swift. This means it is available to all Swift projects with no additional downloads, maintenance, configuration, etc. This is a nontrivial benefit which increases with configurabilty because it would be applicable to more projects, including those that are unwilling to follow the default style 100%.
That said, I think @nicklockwood’s concerns about this tool not receiving the attention it deserves are valid. Done right, an official tool would channel the community’s energy and therefore be of higher quality than could be achieved via independent competing open source projects. Done poorly, a standard tool would be unfortunately limited relative to competing open source projects but would zap the energy and motivation to continue developing those tools.
I think it’s important that if we do tackle an official tool we are committed to doing it right. Realistically, that means the organizations that propose the tool should be willing to commit to investing the engineering resources necessary to do so. It must be a best-in-class tool by any reasonable measure. Anything less would be harmful.