WinRT is a replacement for the age-old C-based Winapi. It is an api that must be usable in many runtime environments. Back 20 years ago, a C api was relatively easy to interop with. That has moved on since then, COM became the universal glue in the last half of the 1990s. Practically any language runtime in common use in Windows supports COM.
A garbage collector is a language runtime implementation detail. The collector for .NET is very different from the collector for Javascript for example. The native objects created in either must observe the very strict rules of the collector. Which in turn means that they would have had to create WinRT versions that are specific to each language runtime. That won't do, even a company as big as Microsoft cannot afford to create and support a specific WinRT version for every language binding. Nor is it necessary, given that these languages already support COM.
Right now, the best binding for WinRT is C++ since COM works more efficiently with explicit memory management. With ample help from the new C++ compiler extensions that make it automatic, very similar to _com_ptr_t of old with C++/CLI-like syntax to avoid it. Binding to managed languages is relatively simple since the CLR already has excellent COM interop support. WinRT also adopted the metadata format of .NET. Afaik, no work has been done at all on managed compilers as of today.
EDIT: Larry Osterman, a well known Microsoft programmer and blogger, left a rather good comment in a now deleted answer. I'll quote it here to preserve it:
WinRT is unmanaged because the OS is unmanaged. And by designing WinRT the way it was designed, it gains the ability to be expressed in many different languages, not just C++, C# and JS. For instance, I could easily see a set of Perl modules which implement the WinRT APIs which work on the desktop. If we had implemented it in .Net, that would have been extremely difficult
