Earlier quoted context omitted.
I think there is a contention in what MV* preaches and the reality of UI development now that it is disconnected from the server. Traditional MVC has followed a struts like architecture where the C is a procedural workflow that starts at A and end at Z. This encouraged a dumb V where say the header of a site was an HTML template and that the C would then populate with the M. This benefited the service oriented nature…
I think you forget that MVC is a pattern and not a specific method or an implementation. MVC could care less whether something is procedural, evented, client or serverside.
(From the article: One of the central ideas of the Smalltalk-80 system was the ModelViewController (MVC) UserInterfaceParadigm?. Within that paradigm, the term "controller" had a well-defined, limited meaning.)
MVC today does not have a specific method or implementation and that was my point MVC has come to be known as a fuzzy definition for separations of concerns, as such I believe just saying separation of concerns is a better definition of what is desired. Because at some point people look at what was modeled in Smalltalk or Struts 1.0 which adhere to that concrete definition and become confused with the more nebulous definition that MVC has morphed into.