Most people who are really into ASP.Net MVC probably enjoy its test-driven nature or "unit-testability". This is a key benefit of the asynchronous model used by the MVC framework when action results are returned. Another benefit of this is in memory management.
I am working on creating a large document which is to be available both online and offline and consists of several hundred (potentialy more than a thousand) items. The items are stored in a tree structure where each item has children and children can in turn have children, etc. Each item generates about one printed page worth of HTML.
At the risk of beating a dead horse, I'm going to compare MVC to Web Forms. In web forms, you would typically create a user control or custom control to render each item then within that contol you would add child controls for each child recursively. What you may not realize is that this builds a giant control tree which maintains all of the dependent data throughout the page lifecycle.
In MVC on the other hand, you would (most likely) build a partial view and render it using Html.RenderAction. This means that each item received its own trip through the MVC framework, instantiated its own controller, grabbed the required child data and passed it to the view engine to be rendered. This means that your model is out of scope and once the references are released by the rendering engine that memory is freed up. In essence the only memory accumulation is for the actual HTML output eventually streamed back to the client and everything else is freed up for garbage collection as each partial view is rendered.
Thanks MVC!