What I find confusing about the Smalltalk diagram of MVC is that the view can update itself from the model without help from the controller (and without the controller even necessarily being aware of it), but updates to the model based on view events apparently have to go through the controller. This raises the question of why if the view is capable of reading the model on its own, it is not likewise capable of modifying it, and/or conversely, if the controller is used to customize how the model is updated based on view events, why it can’t also be used to customize how the view updates itself from the model.

What would make more sense to me is to simply define the controller as an intermediary between model and view for updates in both directions. The controller would simply represent whatever needs to be specific to the particular combination of model and view in the particular application context. Depending on context, you might use a no-op controller when no customization is needed, as in the example of the article where a checkbox (view) is bound to a boolean property (model).

This is exactly how I conceptualize and use "MVC". The controller mediates all communication between the view and model, and in fact drives everything.