This is conceptually nice. But consider. You want to fork a third party library. On check in you reformat the entire code base? Or, if you don't do it on initial commit, and then somebody needs to modify one line?
Recognize that "third party" might not mean some code base from NVIDIA or whatever, but just some code from 5 years ago in your own company.
And sure, we could enforce the same tool chain on the entire company, but then you have broken diff on probably every line of code in every repository. And the embedded guys are up in arms because it makes bad decisions for their hardware, which is limited to 40 column displays. And so on.
Go got it right. They had green field development, and made the decision on formatting then. I'm not crazy about a few of the specific choices they made, but who cares, really?
Personally, I would like a tool that inspected the code, recognized the style, and then enforced that style. Braces on the same line, well, that is how all new lines will be formatted. And so on. I live and die by source code diffs, and don't want formatting wars to break that. I also spend every day in multiple code bases not written by the company, so I already deal with different formatting styles. It ain't hard to deal with, excepting that terrible Microsoft C style of spacing ('foo( x ,y )' vs 'foo (x, y)'. My eyes can't parse that quickly because it breaks all the normal rules of punctuation that we use in English and every other computer language. (I don't know that MS invented it, it is just pervasive in their code, and it is where I usually encounter it)
All of that is not to say I completely disagree with your idea, it is attractive in a number of ways, I am just pointing out some tradeoffs (and putting the lie to your "no more arguing" ;))