Maybe I'm off and what I'm describing is MVP rather than MVC, but the experience I described is usually the strict interpretation for MVC, whether we're talking about a PHP framework or an iOS app in Objective C.
Edit/Update: ...however, there are times or projects that really need a modification to the "strict definition". For instance, a more modular approach works well at times, and thus you'd have to break some of the MVC/P rules. I did just that at work for a internal PHP framework and it's be a complete success, so obviously I'm not arguing you "shouldn't" or that it's "bad", but the author was discussing what he thought was the traditional definition of MVC, and that's where we disagree slightly in regard to models.
Basically, there is no difference between:
<?php echo $data['email']; ?>
<?php echo $data->getEmail(); ?>
Take your list code in HTML example. You can easily create a view that asks for data from a model, and simply ensure that the model always uses the same interface. Now, any model that should be listed has the same interface the view can access.
Views shouldn't be running actions on the model, of course. But it makes no sense to take data from a model, compile it up, and send it over to the view, when you can simply send the model to the view.
Having the view talk directly to the model actually makes the code a lot simpler (and a lot less of it).
If all your view can get from the model is "a giant dump of things", there is probably something missing from the model. Because in that case, all the controller can get is also "a giant dump", which means you will need to add business logic to the controller to process this giant dump for the convenience of the view. Which puts us right back where we started: bloated controllers that contain business logic that should be in the model.