You lose reusability/modularity though.
Let's say I have a view which displays information about a user. Their address, email, name and all that.
If you have a controller doing this:
$user = $this->user->findById($_GET['id']);
There are several concerns here:
-This code needs to be repeated wherever the view is used.
-The controller could inadvertently omit to set the user variable
-$user can be anything. Is the view expecting an array? An object? A primitive? There's no way to know.
Whereas if the controller is doing this:
The controller is now agnostic about display concerns (what speficic information is needed by the view) and the view can be initialised from anywhere without the repeated data fetching logic.
In the real world, this makes a big difference when it comes to maintainability. Imagine the view is reused a dozen times and some extra information needs to be added. For example, the latest post the user has made. You now need firsly locate where the view is used, then go through a dozen controllers and add the binding logic for the post. If the view has access the model, you make the change in one place: the view. Which inquires from the model about the new information it requires.
Wherever the controller contains display logic (e.g. pagination, forms) this logic needs to be repeated which is at best messy. By moving the display logic where it belongs--the view, it's entirely reusable.
By giving the view a firm contract with a model, the view will always know what is available to it, and it will always be available. It's never possible to create state where a variable hasn't been passed into the view by the controller. This is, in effect, the premise of something often referred to as "design by contract" which itself has many benefits when it comes to writing testable and reliable code.
Whether this is on the web or a desktop application is irrelevant. The same pros/cons apply. The only part of MVC which is redundant is view refreshing (Which is an extension of the pattern anyway)