Why MVVM?

• The event handler is part of the "code behind" where the UI is declared, typically a window or a user control. This makes it difficult to call from other objects that may want to invoke the same logic.
• The aforementioned button may disappear and be replaced by (say) a menu item. This would require the event hooking code to potentially change. What if we wanted both a button and a menu item?
• An action may not be allowed at a certain state – the button (or whatever) needs to be disabled or enabled at the right time. This adds management overhead to the developer – the need to track state and change it for all UI elements that invoke the same functionality.
• An event handler is just a method – there's no easy way to pick it up and save it somewhere, such as for undo/redo purposes.
• It's difficult to test application logic without using actual user interface.

These, and other, more subtle issues, make working with event handlers less than ideal, especially when application logic is involved. 

If an event is just intended for usability enhancement or for otherwise serving the UI alone, than this is not usually a concern (for example, hovering the mouse cursor over some element causes color changes, enhancing use experience in some way – although even this can be achieved declaratively with triggers.