In my experience, MVC appears to be largely overengineered, up until you have models that are subclasses of each other and could share the same view. Then I've had it cut development time in half for the second model (including the time to break down the first to MVC) and even better for subsequent objects. Even then, people are too married to having three initials and you get entire ragefests over "omg where does the valdiation go WHERE DOES THE BUSINESS LOGIC GO?!?!?!" (most "business logic" I've seen used in arguments over business logic could be trivially implemented as a second model that operates as essentially a parameterized view on the database covering a certain subset of objects, eg "bob's sales prospects" = select * from prospects where owner='bob'. Then code is like list = new EmployeeProspects('bob'); list.addProspect(new Prospect(...)); etc where EmployeeProspects is responsible for munging the Prospect object's database entry to fit (add) or not fit (remove) the view, and throw exceptions when it cannot or should not.)
As a use case for MVC, consider Pizza Joe's website. Sure, you can slap together a page that lets you order from a list of hard-coded ingredients to make a pizza, 1 hr. But think a "Pizza Builder" view where the model is the pizza, until one day the boss says "let's let people save pizzas for ordering again in the future" so you reuse Pizza Builder view but the model and controller is for a SavedPizza. Then the boss wants to be able to put together special pizzas and name them "let's let us make a Joe's Deluxe Medium Pie for $10" and put them on sale, so reuse the Pizza Builder view for PromoPizzas. Then the boss wants to be able to create promo pizzas to schedule in the future using ingredients that don't exist in the database yet so he says "let's let us let lettuce be a topping next week" so you flip the table and storm out. Or create a FuturePizzaBuilderView for PromoPizzas (or better yet, create an IngredientList/FutureIngredientList model and redo PizzaBuilderView to accept that from its constructor, and the various Pizza controllers to select an appropriate IngredientList model to provide the PizzaBuilderView. Dependency Injection!