in ASP.NET MVC the request comes in from the web server and is handled directly by the Controller. The Controller determines the appropriate View and populates it with Models. The Controller then releases these instances to the underlying system which renders a result to the client. You can see that the Controller is first and last to act.
In MVVM, the UI (the View), faces the user and takes user input directly. Within the View, Commands within the ViewModel (which is the DataContext of the View) are triggered by this activity. Control flows to the ViewModel which interprets what the View has sent it and prepares its Models. After control flows back to the View it updates itself according to changes in the Models. If a new View is required, the ViewModel communicates this with the NavigationService (or whatever method of navigation your application uses), which is the purview of the Window or Frame--UI components. You can see that the ViewModel isn't first and last to act; the View plays a much greater role than in MVC.
As far as choosing which one is best, I would tend to be guided by tooling support. For instance, if you are using ASP.Net, there is a tremendous amount of automation through the MVC project template that helps with the boiler plate setup and use of that pattern in an application. From what I understand about Silverlight/WPF, there is a lot of support there around MVVM. When I was coming up to speed on MVC/MVP a few years ago, I implemented MVP in the checkout process of an eCommerce application. It was a great experience with a satisfying outcome, but I was writing everything by hand with no tooling support and little guidance. When I write a Silverlight app, I will certainly be moved toward MVVM because of the support that is there.
