MVVM isn't outdated, but it was overplayed to begin with. I never liked it and it kept me in WinForms for too long; failing to see the forest for the trees, I threw the baby out with the bathwater. I get WPF now, and I get the idea of not wanting to mix code with markup, but I prefer the Android style of sticking the markup in one place and dereferencing it with casts in my code (which you can also do in WPF, even though it never got trendy to do so for whatever reason).
That way you gain more fine-grained control and don't have to worry about all the "onchanged" handling everywhere. I feel this is actually more testable because tests won't always catch it if you miss an "onchanged" event.
You lose a bit of "declarative"-ness, which seems to be a trend these days (e.g. if two widgets are mapped to the same value, in MVVM you can just do that, whereas with imperative code you have to set both individually). But even with MVVM, that only works in the menial case. If some widget has to display the log of another widget, then you've got to write another handler and another "onchanged" event and so you end up having to stretch the definition of "declarative" to say it is so.