Microsoft's assembler uses Intel syntax, and their inline assembly also uses Intel syntax.
Their inline assembly is much less explicit about inputs, outputs, and clobbers, and "just" has you mix C symbols and labels with assembly instructions, which I imagine is a pain to get right.
However Microsoft has de-emphasized inline assembly and doesn't allow it on amd64 or ARM. For things that need specific instructions you need to either use intrinsics or put assembly in a different object file.
That's just sad :(
But the way they had it, they presented a seamless blend of assembly instructions and any C identifier, in or out, and I guess the compiler would need to parse out any side effects and cope with them. My guess is they looked at porting all that to ia64 [which they supported until Server 2008 R2], amd64 and ARM and balked.
No idea if they ever had it on some of the old architectures they supported in NT4 days or on CE (alpha, mips, ppc).
Examples: An abort call on an embedded system that needs to disable interrupts to prevent task switching after the abort. One instruction.
An implementation of _start for embedded that can do everything in C except setting a couple processor flags. Two instructions.
Running (with a lock) event callbacks in an embedded system on their own stack, so that not all tasks need to have their stack big enough to handle the stuff the callbacks might do; 5 instructions that are far better inlined than having another call and indirection. (In addition to keeping doc/code together).
That said, this is a good decision because C compilers seem to be the major holdouts at this point—binutils has had .intel_syntax for a long time now, it’s just not supported inline.