The problem is that the Enterprise market is moving to the web. Most enterprise applications are database-centric, so a network connection is a must. At that point, the obvious advantages of server-based logic overcome any limitations of the browser-based frontend. If your application logic is going to be on the server - and be massive (as is the case in many enterprise apps), it makes no sense to build that logic on any specific desktop - or device - platform. A web browser provides you with a smart terminal interface that is implemented on every possible platform.
Historically, people built enterprise apps on the Windows desktop, because the web browser UI was simply not robust enough for serious data entry. Those apps were hellish to support in the field - and slow in accessing a remote databse, but they kind of worked. Well, those apps exist, and many will continue to be supported - and even developed. But what will not happen is rewrites of those apps as Windows universal apps - or any frontend-specific paradigm. It's too late for that. It might have had a chance if existing Win32 code could be easily leveraged, but full-out rewrites, not likely.
But I suspect that's not what Microsoft's after here. They want an in to mobile, and those relatively simple mobile apps, and games, etc that don't work well as web apps and are small enough to rewrite for various platforms (hell, most of em are already supporting iOS and Android ports). That could work, though it sure doesn't have to. Most of those apps are mobile only anyway, and they already work on 95% of devices (i.e. iOS and Android). The chicken and egg problem isn't going to go away just because Microsoft makes it easy to leverage your mobile app to the desktop. The only leverage Microsoft has is the reverse of that - desktop to mobile. And, like I said, desktop apps either already exist as Win32 code or will be written as web apps. So that leverage is minimal.