Microsoft's Problem with Legacy APIs
Each new API that Microsoft introduces either wraps existing APIs (MFC, WinForms, ...) or is a subset of the APIs it intends to replace (GDI+, .NET, WPF, Silverlight, WinRT, ...), while offering new functionality not available in the other APIs.
Take the .NET runtime APIs for example. They are not a complete replacement of the Win32 APIs, forcing you in cases where you need that functionality (e.g. interacting with existing Win32/64 code) to use P/Invoke. However, Microsoft don't provide a set of P/Invoke wrappers for the Win32 API or include them in the corresponding Win32 documentation on MSDN. This means you end up with duplicated P/Invoke declerations that may contain bugs if incorrectly declared (e.g. unicode support).
For Win32 programs, the underlying Win32 API does not provide UI functionality such as Docking/Floating toolbars; these are written in the wrapper APIs (WTL, MFC, WinForms, ...), so you end up with an inconsistent user experience (accessibility, theming, keyboard shortcuts, ...) and more duplicate code.
The .NET 4 runtime is the first version that WPF/XAML properly supports rendering fonts on the screen, making it acceptable for UIs. However, it still lacks UI available in Win32 (date/time selection), renders keyboard focus for things like radio buttons and check boxes differently to Win32 (focus is on the checkbox, not the text) and keyboard navigation is also inconsistent with Win32.
Now, with WinRT, the XAML available does not support everything that WPF does and still does not have equivalents for all the Win32 native controls. The WinRT subset of Win32 is severely limited and restricted. This means that WinRT applications are going to be simple applications. Companies with their existing Win32/WinForms/WPF applications are not going to port their applications to WinRT overnight, and if they do are more likely to port their mobile versions over, not the desktop versions over. This is because desktop and WinRT are completely different platforms for all intents and purposes (e.g. it is like porting a Win32 desktop application to WinCE or WinPhone).
I don't believe WinRT in its current form is capable of supporting a large scale application (MS Office, LibreOffice, Firefox, Photoshop, etc.). Note that the firefox version targetting Windows 8/WinRT is not a pure WinRT application, it is in the hybrid Desktop/WinRT application category that is reserved for browsers that give it access to capabilities that true WinRT applications do not (e.g. the Virtual* API calls to support JIT compilation of JavaScript).