But also accepts Intel syntax with a directive, and even admits "almost all 80386 documents use Intel syntax" [1].
As for user acceptance, a poll on the xkcd forums shows that the vast majority of users prefer Intel syntax [2].
That takes care of the political/network effects arguments. As far as the actual technical arguments, the position against AT&T syntax is obvious and overwhelming -- the unnaturalness of src,dest operand order; the lazyness of the parser's authors at the expense of its users by requiring percents or dollar signs to indicate token types; the usually-redundant size postfix; and the utter incompatibility with basically all non-GNU x86 documentation.
Strictly imho, the translation overhead of reading one or the other if you're used to the opposite syntax is not that high. We're not talking haskell vs. c++ here, it's operand ordering and maybe a few characters' worth of difference in the commands (e.g. add vs addl) or typing register names and so on. The basis of my opinion, fwiw, is that all of my classes involving asm used GNU tools/AT&T, and I never felt enormous difficulties reading Intel-inflected docs. It's quite possible that I was just lucky enough to have never been bitten badly, I don't know.
So while I don't disagree with your technical reasoning, I don't think that it's a significant pedagogical barrier. The puckish part of me wants to suggest that having to figure something out when the documents are a) insane b) backwards c) written in Martian d) all of the above is great preparation for commercial work. ;)
The reality is you just don't need to write a whole lot of assembly day-to-day so using what the tools support best tends to be the path of least resistance.
Xv6 itself has about 5000 lines of .c and 364 lines of .S in the kernel. Another 1500 lines in vectors.S but that's machine generated. There's a ton of stuff one could add to Xv6 (drivers, syscalls, services, etc), almost all of which one would likely just write in C.
In practice, I've found assembly mostly used for some hand-tuned inner loops (codecs, memcpy, etc) and little snippets of glue code like entry.S, swtch.S, etc.
