In that case, the guys from Microsoft are not engaging the brain then. The Build talks that spoke about LOB apps in Windows 8 place heavy emphasis on moving to the new UI. They spoke about 98% of LOB apps can be moved over. They repeatedly state that developers should "move their apps forward" to the new UI. They repeatedly state that the desktop is the "old" and that we should move to the "new".
Build is about new Microsoft technologies. That's why they talked a lot about the new UI.
And yes, you can put some LOB swishy apps in the new UI. But Microsoft aren't expecting you to migrate your massive WinForms projects into an iPad-suitable format any time soon.
To me, this points to the fact that the desktop area is entering the legacy phase.
Let me make this very clear. Microsoft goes to freakishly bizzare efforts to make your apps from Windows 95 work on Windows 7. They have teams of people to patch opcodes in Adobe Reader 6 to make it work on Windows7 and they hook GetVersion() to return "yes I'm really Windows 98" for the apps that say if(GetVersion() != Windows98) abort().
That right click menu on shortcuts to change what compatability the app runs as? That took thousands of man days testing millions of products to build.
They refused to change the default caption size in Windows7 because it broke a couple of minor apps that frankly nobody's ever heard of, and that annoying thing where for ages running VLC would cripple Aero and take you back to the "basic theme"? AppCompat yet again.
Microsoft refuses to change function signatures and can't kill old crusty functions like GetAtom() - which returns an ATOM not a BOOL for the one program written in 1997 that gave a crap, and a cursory examination of LoadLibraryA shows that the first thing it does is call strcmp(_param, "twan32.dll") to keep some old crusty apps from breaking.
There's shims in Microsoft for Baldur's Gate, thunking layers to take DirectX9 apps to DirectX11 because DirectX9 doesn't exist in Windows8, and the entire WOW64 layer is there to keep apps compiled for 32-bit by emulating every single damned syscall because the kernel contains only 64-bit code.
There's even an entire fake directory structure in the Windows directory and the registry (C:\Windows\syswow64) which appears as C:\Windows\system32 to 32-bit apps just to maintain binary compatibility with old and crusty apps that aren't 64-bit aware.
My point is that Microsoft goes to absurdlengths to make sure that an app you compile today will work 10 years down the line, no matter how much they change under the hood in Windows. There is not a cats chance in hell that Microsoft are going to stop supporting desktop applications in the foreseeable future - not after they've staked their entire reputation on maintaining binary compatibility with apps from before coding standards or MSDN online documentation existed..
So when you say "Oh, I should stop writing apps for the desktop because Microsoft might can the desktop in the next year or so" my response is thus:
The desktop is here, it's here to stay. And frankly if you're worried about the future-proofness of your apps, then look at WPF versus WinForms. New things are easier to bin than old things at Microsoft. So don't believe everything you hear at Build.