Yep, that is why people should not use one. The reason there are so many frameworks is because everyone for the past 15-18 years has been trying to fit the same square peg in the round hole. With the proliferation of RESTful services and RIA/Javascript application, there is no need for server side frameworks short of a small framework to expose your logic as a RESTful service.
Wow. I couldn't disagree more. Having plumbing like MVC and ORM built-in increases speed and means less code to maintain. The selection of which one (i happen to like Django) may be a toss up, but there is huge value in a server-side framework.
ORM and MVC are not the exclusive domain of a web framework. They are frameworks in and of themselves. That is the problem, people think of the data (ORM), the controller and the view framework as the same thing because they have all been lumped into these "Super Frameworks". They are not and they do not need to be. The old page-post model of web development is antiquated and the frameworks are now trying to deal with that fact by bolting AJAX on top of them and making an even bigger "Super Framework" but there is really no need and it actually pollutes the frameworks with opposing development philosophies; creating more complexity rather than reducing it. The fact of the matter is, that the server only needs RESTful endpoints and an ORM framework (if you are using an OO language). Services by definition represent server logic controllers.
As for the view, they are better served by an event driven framework than they are by MVC in which UI elements are encapsulated and message the greater system via events. I have done it the page-post way for a long time and was a resistant convert, but after building web and mobile apps the new way I have come to find that it is much cleaner and faster to pull the UI off of the server, if it had not been for the browser wars we would have been here a lot sooner.