Wow you have your angry hat on today. .NET apps won't be going in the bin anytime soon (there's code in ntdll.dll to specifically speed them up in Win8, and MS wouldn't have done that if they didn't like .NET), and you seem to have got confused about the distinction between the Windows team and the rest of Microsoft. The only thing that the Windows team have final say over is the kernel (and there's some pretty hefty restrictions on what they can do there too) - everything else is done collaboratively with the rest of Microsoft. Stuff like the Ribbon and WinRT and the rest of it came from outside of the Windows team, and the Windows team just gave it go-faster stripes.
It's not anger. It's disgust. This whole WinRT thing is politics. Windiv didn't have the time to move everything over to WinRT so they still depend on .NET. You have to ask yourself "why did the HTML5/JS story come out first?", "why is there so much talk about native?" IMO it's pretty simple; windiv is going for a power grab. They need to bring over the SL/WPF/.NET devs to WinRT so what do they do? They try and make it easy to port your XAML over by keeping the controls syntax as similar as possible. They've done the same with other WinRT APIs and made them easier to use over their .NET counterparts in some cases. Like as been inferred before windiv thinks the whole Silverlight thing was a mistake and they are trying to reign it back in. This is politics pure and simple. Just like the republicans use the economy as the smoke screen for their power grab, windiv uses the losses to Apple and Android as their justification for their power grab.
I truly like where they are going with WinRT/Metro. By playing the bundling game (phone-like experience w/desktop) I beleive they have a shot. I also believe they could have performed the same re-inventing of Windows using Silverlight and .NET as the basis rather than putting a wrapper around COM, calling it WinRT, and porting XAML to it. The same eco-system of contracts and capabilities that are in the WinRT/Metro stack could have been added to SL/.NET (or at least a special runtime mode of SL) rather than re-inventing the wheel.