Keep in mind that Windows emphasizes a unified ABI on AMD64 largely because of what happened on x86. The x86 ABI sort of evolved into this "wild west" kind of situation, with various calling conventions for different languages/runtimes and usage scenarios (i.e. stdcall, cdecl, fastcall, pascal, etc.), which ends up making things unnecessarily complicated for the OS. (Kevin has an old blog post where he discusses this in more depth: http://blogs.msdn.com/b/freik/archive/2006/03/06/x64-calling...)
Being a good OS citizen and sticking to the Win64 ABI also makes some things significantly simpler for the rest of the runtime. An obvious example of where this pays off is native interop (e.g. P/Invoke, COM interop, C++/CLI), but one less obvious example of where this comes into play is actually managed exception handling (which is built on top of the underlying Structured Exception Handling mechanism that Windows provides). Not only does adhering to the unified ABI allow managed exceptions to interop with native exceptions, but it also makes things simpler for debuggers, anything that needs to walk the stack, etc.
Remember, the CLR is really more of an execution engine, and not so much a "virtual machine". We try not to disrupt the architectural conventions of the underlying platform, since we're not trying replace the OS environment itself.
Being a good OS citizen and sticking to the Win64 ABI also makes some things significantly simpler for the rest of the runtime. An obvious example of where this pays off is native interop (e.g. P/Invoke, COM interop, C++/CLI), but one less obvious example of where this comes into play is actually managed exception handling (which is built on top of the underlying Structured Exception Handling mechanism that Windows provides). Not only does adhering to the unified ABI allow managed exceptions to interop with native exceptions, but it also makes things simpler for debuggers, anything that needs to walk the stack, etc.
Remember, the CLR is really more of an execution engine, and not so much a "virtual machine". We try not to disrupt the architectural conventions of the underlying platform, since we're not trying replace the OS environment itself.
--Henry Baba-Weiss [MSFT]