I am writing this in response to Harry Fuecks – MVC and web apps: oil and water post on Sitepoint.
Let me first say, that I have yet to have a product make it to production that follows strict MVC, however the pattern is becoming a strong feature in our application design process.
The largest stickler with MVC, is seperations of Data and Presentation. This is remarkably similar to the current web standards push of seperating Semantic Markup (Data) and Design (Presentation) through the use of CSS-P. This is, I believe another small part of why MVC is seeing much more hype lately. Go look at a lot of Ruby on Rails websites, see how many are using CSS in abundance?
However, there are other reasons. I am now looking to re-write a large application, and MVC is becoming more and more tempting. The reason for this is that with the web evolving as it is, we need to ensure data integrity beyond handling form submissions.
We are now needing to serve the same data, and allow the same backend processes to happen through multiple means. There is the standard “Database -> PHP -> HTML (via a template) -> Browser -> Client -> Form -> Server -> PHP -> Database” workflow and in addition there are new workflows like these (highly simplified!):
Web Services
“Database -> PHP -> (SOAP|REST|XML-RPC) XML (via a template, albeit it usually a code toolkit usually) -> Soap Client -> Response -> Server -> PHP -> Database”
RSS
“Database -> PHP -> (RSS|RDF|ATOM) XML (via a template) -> RSS Reader”
AJAX
“Database -> PHP -> HTML (via template) -> Browser -> Client -> Web Control (link, form) -> Server -> PHP -> Database -> (XML|JSON|HTML|Plain Text) via template -> Browser -> Client -> …. “
Note: All of these denote the linear order of events, its not meant to replace a nice UML Workflow diagram or some such 
Therefore, with all these access methods, it is my view, that Data Integrity is the single most important part of a web application. Be that integrity in the database, or integrity in getting it to the client correctly. Everything else in between doesn’t matter in the grand scheme of things.
Therefore, having a rigid set of Model (Data Manipulation and Retrieval), View (Generating HTML, XML, SOAP, XML-RPC, REST, RSS, RDF, ATOM, JSON, Plain Text) and Controller (Handling Web Service, RSS, AJAX and standard browser requests) does suddenly seem like a great way to plan for adding methods of handling new client data retrieval techniques without futzing with every aspect of your application (what happens when SOAP 2 is released? or a new feed format? Adding support for these should not impact any other “View” of your application)
– Davey