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.
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)
And wait until they lose interest in WinRT too like they have done with every new technology quickly.
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.
http://msdn.microsoft.com/en-us/library/ef2xyb33
WPF main advantage over Winforms is XAML vs tool-generated designer class IMHO. Most of the other concepts have their equivalents in both technology.
• 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).
http://www.codeproject.com/Articles/17188/Inversion-of-Contr...
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.