Well, there are a few good reasons for that: coding for WinRT is harder than it should be, and the developers are not fans of the WinRT UI (so they don't use it).

I am in this very situation, with an app with has dozens of millions of users on Windows (and millions daily).

The first reason is the most important. WinRT requires a lot of rewrites of your code. (and the rationale behind some limitation are often political), and Microsoft is not helping or making it easy for you Notably for networking and multimedia.

Networking: everyone uses the BSD sockets, Win32, Linux, OSX, iOS, Android, Symbian, Bada, etc... And you cannot use them on WinRT. There is a very high chance that your code or one of your library uses it, of course. But the bad part is that Microsoft does not make easy with a wrapper exposing WinSock-like API based on their new API. Not even a wrapper than does 80% of the needs.

Multimedia and Games: your videogame that works with a C++ engine and OpenGL ES for casual games that works on iOS, Android, Bada,... does not work under WinRT, because OpenGL is not allowed... And I don't even speak about Video acceleration.

Yes, they need to do a massive change in their APIs, but helping the transition would have been a good idea...

So yes, writing yet another Twitter client is easy on WinRT, for more complex applications, well, it is way too hard and difficult to do it this fast.