I get it: a UWP app might be noticeably faster with AOT vs. the standard CLR JIT, but for a UI program that isn't crunching numbers, you are unlikely to tell the difference. Also, the CLR, like the JVM, is no slouch when it comes to running things. As such, there is always a huge asterisk attached to AOT claiming it might improve performance, but it could also degrade it, it is hardly an obvious win. The way it was explained to me was that AOT is necessary for UWP to support IoT and lower end hardware, that on full computers you probably won't notice.

Also, look at all we gave up for AOT. Dynamic compilation in the DLR was pretty nice...and it was reduced to an interpreter in UWP because....no JIT. Granted, I was probably the only person to notice because no one else probably thought to cross the two.

The problem with Microsoft is that as soon as they move to the next thing, they basically abondon the previous one without having the next thing truly replace the previous one. So here comes UWP, meant for "different" things, but it gets all the new stuff while WPF is basically dead. Ya, want to use those new APIs? Sorry, you'll need to use UWP even if you have no intention of running on low end android devices.

So much good stuff, but you have to make a Faustian bargain to use them.

Yeah F# is a good example.

Two years after UWP was introduced still no roadmap in sight for .NET Native support, Visual Studio 15.3 just shipped with the F# team telling people to use VS Code instead.

I bet it will be joining Silverlight in a couple of years.

However Microsoft is not alone in these kind of decisions. I can think of a few similar ones from Apple, Google, IBM, HP, Oracle, Sun,....

Ya, I wouldn't single out MS as particularly bad here, but they used to be much better about this than the other companies. Now they are reaching down to parity, and developer support used to be their greatest strength.