The very definition of MVVM is that the ViewModel is an abstraction of the View. None of the knowledgable MVVM advocates have made the claim that the View should never directly access the Model, though there are good reasons to prefer not doing so.
In any event, it's highly unlikely there will be a one-to-one relationship between the ViewModel and the Model. Heck, it's possible there won't even be a one-to-one relationship between the View and the ViewModel, though that's far more likely.
Some comments on the "article" itself:
* You're going to confuse readers when you call the pattern Model-View-ViewModel but then say the "most approved description of this design pattern" (approved by whom?) is Martin Fowlers article on Presentation Model. Honestly, there's enough confusion
about whether or not these are the same pattern (they are!) and if they are, why we have two names. Not mentioning the details here is just going to make matters worse.
* If you've thrown a controller into the mix, you're not following MVVM/Presentation Model, but some other pattern. I'm disappointed that little about this is discussed.
* IView is never defined. This article presents this as a single pattern, but seems to be an implementation of multiple patterns, rather than a pattern itself. If it is a pattern, stuff like this needs to be defined.
* Weak events are not a WPF concept. For that matter, neither is commanding. Though these live in assemblies associated with WPF, they are usable in WinForms (commanding less so, due to the lack of ICommandSource on controls in WinForms, but that can be
* The stricture about "having to" use weak events when the ViewModel listens to events on the Model uses a stronger statement than you should. You're likely to need to address lifetime, and weak events are one way, but this isn't a "have to"
scenario. Oh, and this statement backs up what I said in the last bullet point, as the ViewModel and Model have no relationship to WPF at all, and yet you're employing weak events ;).
* I've not looked at the WAF project, but the discussion about all Views needing to implement IView makes me cringe. There are abstraction solutions that won't require tedious reimplementation of an interface all over the place, which probably isn't
going to be a very DRY architecture. An IView interface isn't a bad idea, but it should be something provided by the framework and not something the user has to implement over and over again.
I am interested, though, and will check WAF out when I get the time.