* Separation of concerns.
* Create more beautiful and succinct HTML.
* Handle alternative logic paths easier via Action overloading.
* Reuse code between related pages better (because they’re all actions on the same controller).
* Avoid having to deal directly with untyped query parameters.
* Avoid having to bind complex forms to nested objects in code by using a single attribute (where as with data binding I’m often left with having to surface deeply nested properties via a custom type descriptor, or to manually assign the properties myself from the control values)
* Ability to create view components to save repetitive markup but support customization in a more lightweight and flexible manor then controls/user controls.
* Easier to understand page flow i.e. button that submits to controller a, action b, will display b’s view.. as apposed to the common button click on page a submits to page a where an event then decides to redirect to page b (you don’t know until you check the code). Can be avoided in asp.net though, so probably doesn’t count.. just a common bad practice.
* You can test both controllers and views independently of each other, TDD friendly.
* Concise, you write less code – and the model i.e. using Flash & PropertyBag to provide data to the view, makes reuse of controller logic a great deal easier (because it’s not tied to a views implementation).

ASP.Net Webforms:

* Has a design-time experience, useful for configuring some complex controls.
* Allows winforms developers to migrate existing knowledge about data binding, event based programming etc.
* 3rd party controls.

That’s enough for now, I have work to do