Microsoft’s argument is that the average programmer can’t write very good assembly and that the compiler will generally produce better code (a belief that, demonstrably, rarely holds true with experienced C programmers). 

What Microsoft doesn’t know is that: 

1. Not everyone who uses Visual Studio is the aforementioned “average programmer”.
​
2. The fact that a block of inline assembly may mess up the optimization of the rest of the function is rarely a problem; primarily because more often than not, the bit that really needs the speed is a few lines of code inside a loop inside another loop. If the rest of the function slows down by 50% and that bit speeds up by 10%, the overall gain is 9.999999999999999% – who gives a hoot about the optimization of the rest of the function?
​
3. People benchmark their assembly against what the compiler produces, and that is how the decision to use inline assembly is generally arrived at. Contrary to Microsoft’s beliefs, those of us who use inline assembly don’t just shoot in the dark.
 
4. C programmers, unlike their C# and .NET counterparts, generally hate being babysat, primarily because they don’t need to be. When a programmer needs to be babysat by their compiler, they generally switch to a “softer” language. The fact that a C programmer has elected to get into the basement via an __asm{} block should tell you something.
 
5. Every compiler out there, including the compilers made by the guys who manufacture the CPUs that we run both Visual Studio and the compiled code on (Intel), support x64 inline assembly. Believing that all these guys don’t know what they are doing is hubris of intergalactic proportions on Microsoft’s part.