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).
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.