A lot of the criticism I've heard stems around the steep XAML learning curve. OTOH I've only done WinForms and ASP.NET stuff, so I haven't had first hand experience.
That's a pretty fair criticism. But once you've gotten it, it's very powerful (incredible data binding!). And I think we need to be sure to separate WPF from "XAML".
XAML, for certain, is here to stay for quite a while. I recall talking to Carl Franklin about how Windows 8's UI layer is written in XAML. Given that, I think it's fair to say that the time you invest in XAML won't be wasted if you're a Windows developer. WPF may fade into the background, but WinRT will continue to mature and broaden as a platform (esp. as Windows 10 opens the door to cross-device compatibility)
My guess is most companies will skip Win8 like they skipped Vista. Windows 10 looks to be what enterprise will rally around.
But for fat applications, what's your alternative? Java is, at best, parity with something like WinRT but can't leverage the benefits that MS can bring to users with its native platform (assuming a big, MS-centric enterprise). WPF, as we've already said, isn't going to get any more of the pie. Let's not kid ourselves about Winforms or platforms that haven't even embraced data binding.
In the meantime, you can't cross off Xamarin as a means to bring these WinRT applications to even more device types.
In my eyes WPF's advantage usually boiled down to:
• databinding (which it shares with most other things coming from MS; I think even VB had it; interestingly enough, it's somewhat absent everywhere else)
• decoupling behaviour from visuals
• somewhat related to the last point: templating
Especially the last two are what makes WPF awesome. Databinding is just the glue that's needed for the other two to work awesomely. Being able to say »I want this to work like a ToggleButton but look slightly different« (and keeping all the behavioural logic in place without needing to reimplement it) and »I define how my data will look like in terms of the same containers and controls that I build my UI with and (usually) have no performance disadvantage« are the things that are really nice. I take a collection of things, databind them to a ListBox, use a DataTemplate to control how each of them looks and am able to use normal controls in said template that can interact with the data and are not just images pasted onto the UI (like in Swing or Android). And all that without the need to write a single line of code that moves my data from code to UI (or back).
XAML by itself is actually fairly easy to work with because it doesn't actually do that much: At it's core, XAML boils down to an XML-based mechanism for constructing objects. Squint your eyes just right, and it starts to look like the markup for an IoC container:
Where things start to get complicated are the objects that you create with XAML... (which is where the WPF framework comes into play.)
Five or six years ago, I prototyped a system using XAML/WPF to build an HMI system for an industrial process control applications. The system served up XAML from a server that got loaded by a client to construct UI objects. It then inspected the Binding objects that the XAML created and started subscribing to the appropriate server-side data points. It came together within a couple days and really ran quite well.
