[V-2]

In my opinion WPF was MVVM done badly, and never fixed. Having to implement complex converters just to map a couple of radiobuttons to an enum was ridiculous. The amount of boilerplate made it look like a joke. As someone said, WPF makes the difficult simple, and the simple - next to impossible.

[JamesBarney]

I think you statement is true when people tried to follow MVVM with a religious zeal. In my experience WPF/MVVM worked far better for people who took a more pragmatic approach to the code behind.

I always found that WPF/MVVM made the 90% use case really easy, and the 10% use case ridiculously hard. So I usually used MVVM for the 90% case, and the code behind for 10% case. People I know who shared this philosophy with me had a lot more luck with WPF then the zealots.

[V-2]

That may be true, but what does it tell you? To me it shows that the implementation is lacking, if people need to sidestep the pattern on a regular basis, and are actually better off by doing so.

It also introduces inconsistencies - in similar scenario, one dev will already prefer resorting to code behind, another one won't. Plus, testability gets tricky and messy when some of the behaviour can be verified by testing the viewmodels, some can't, and some is actually split over two layers.

All of this at least partially invalidates the benefits MVVM architecture was supposed to bring about in the first place.

Also note that WPF was sort of neglected: it hardly ever evolved over the years.

Ghanhi, when asked what he thought of Western civilization, famously replied that it might be a good idea. I guess the same could be said for WPF : )