This is from an email that I sent out trying to elaborate on why I chose MVC over WebForms for my latest side project.

I wanted to come back to the discussion we had yesterday about the differences between MVC and WebForms.  I don't dislike WebForms, they have their place, I just feel that they are more suited to a form-centric, "business application"-type web application.  I suppose this is because WebForms do a good job of collecting data in a simple way; public websites need to provide a more rich user experience (to meet current user expectations) that seems to be difficult to achieve out-of-the-box with WebForms.

I see WebForms as a component-based model, where MVC is an object-oriented model.  As such, we've seen the ViewState in WebForms require lots of work-arounds in the [our legacy code], for example, because as soon as you try to combine the object-oriented world with the component/event-driven world, there's a mismatch.

Now, as I see it, the decision to use MVC will mean that we lose

• Drag-and-drop page construction
  • As we've seen, you lose that pretty fast as soon as you do anything half-complicated. 
• ViewState, but, as we've seen, this has caused problems and required work-arounds in the past.
  • We don't lose statefulness, just the viewstate and the goofy generated IDs
• Solid componentization
  • There are components and reusable UI elements in MVC, but not a solid as WebForms
• The abstraction of HTML and CSS
  • Sorry, you'll need to know HTML and CSS, but I'd argue that you SHOULD know HTML and CSS if you want to call yourself a web developer (unless you only want to ever work with webforms, only in .NET - why would you limit yourself?)

On the flip-side, we'll gain:

• More consistent object-oriented development
  • Better testability (find a bug, fix it once, and have a test to make sure it never shows up again, BDD)
  • Better decoupling/separation of concerns
• More control over presentation
  
  • More granular control over markup
  • Better statefulness (using client-side javascript and AJAX)
• More marketable skills
  • Knowledge of another Microsoft framework
  • Better knowledge of what good HTML looks like
  • Better understanding of CSS
  • Better understanding of the DOM
  • Better understanding of cross-browser compatibility
  • Better knowledge of how HTTP actually works ;)

Lastly, since you've made me do it, remember those Telerik controls that we used for [the last revision of our .NET app]?  Yeah, they'd work with MVC too:

http://www.telerik.com/products/aspnet-ajax.aspx

Microsoft ASP.NET MVC - ready
With RadControls you no longer have to stick with simplistic UIs in your MVC Views. Telerik UI controls support Microsoft MVC and allow you to combine the testability and separation of concerns of the emerging technology with the richness of traditional ASP.NET server controls. See demo or visit our MVC Forums

Hopefully this has convinced any skeptics that the decision to ASP.NET MVC is a good one.