From all the MSDN sites I follow, and other sources I would say politics.

During those days the Windows division was the one running the OS, C and C++ compilers, while .NET belonged to DevTools division.

So if .NET ever became a success implementing Longhorn, it would mean the Windows division would loose internal power, so many things failed, because instead of improving the languages or runtimes, people would rather see all implode.

So can see how this played by what happened following Longhorn's demise.

Many of the Win32 APIs that should have been .NET code, had been turned into COM APIs. Actually since Vista the majority of new APIs are all COM based (WinRT is also COM).

The Hilo C++ example of the new way of coding with COM for desktop applications was made available.

And the whole "going native" message started coming out of MSDN blogs and there was even a few Going Native conferences before Microsoft merged them CppCon.

The Visual C++ team was ramped up again, as they had moved most of the people out back in the "we are going .NET" days.

The WP 7 with its .NET/JIT model was shown the door.

The COM+ Runtime, which was the genesis of .NET before Microsoft decided to create the CLR instead, was brought back to life but with .NET metadata instead of COM type libraries.

.NET got the Singularity compiler retargeted for Windows Phone 8, with AOT compilation to native code taking place at the Windows store. The MDIL format is native code that just lacks linking, which is done at install time on the WP 8.x devices.

With the going native wind still kind of going strong and Midori ramping down, Project N eventually became what is nowadays known as .NET Native.

So if you look at UWP stack, either .NET or C++/CX, Longhorn is here just based on COM instead of CLR.

I don't know if I am wrong or right, but this is how I read everything that happened, having Windows developer experience since the Windows 3.0 days.