CRUD (Create, Retrieve, Update, and Delete) operations are the basis for virtually all record-oriented database activity. At RailsConf 2006, David Heinemeier Hansson, the opinionated creator of the Rails framework, argued that CRUD and the parallel operations in http (Post, Get, Put, and Delete) and Rails (Create, Find, Update, and Destroy) are all analogous. This is absolutely true.
He went on to argue that in the context of web applications and http, if we "learned to stop worring and love CRUD" (making CRUD operations the only things that are going on in our contollers) the advantages of simplicity, free REST, etc. would all be had directly. Though this may be true, is it reasonable? Abstractly, it can be argued that manipulating objects only via CRUD is all that is needed. But the fact remains that real domain objects transcend records - from the user's perspective, all is not CRUD.
The user has a wide view of objects and systems - essentially because they don't have to write programs that work with them. "Make it do this" is the universal cry of the user. User demand for more functionality delivered in novel ways - to make things easier to use and drive customer demand - is what makes software development a worthy pursuit. The constant fight against complexity and its simplification makes programming fun. Rails works towards simplicity by doing many of the repetitive tasks for you so you can get on with taming the domain complexity - the meat of the problems, the place where developers can have real fun. Users deal with domains; developers translate domains into software - the rest is extraneous. Domains are where the light of programming truly shines.
While web application that is only intended to manipulate related records would benefit from the simplified CRUD view, my experience tells me that real systems are not so CRUDdy. Where more is expected from an object in a web app, there's a lot more going on in the controller than simple CRUD to access the richness of the models of the domain objects. True, real systems with real objects backed by records utilize CRUD at the low levels, but the domain is usually much richer, full of operations intended to make the user's - not the developer's - work easier to do.
Of course, Rails won't force a pervasive CRUD view on it's users. They will be free to continue on as before, with relatively large controllers and complex models. I do think the CRUD emphasis has value, but I believe weight should also be given to the further simplification of domain modeling, and using rails to link systems with common domains together in the dynamic, post-modern ways that Martin Fowler asserted in his talk at the conference. Rails must continue to be a simplifier to move the new web-application reality forward.