MVC|MVC|MVC is more natural grouping than MMM|VVV|CCC.
I find the latter happens far more often than the former for me, so it feels like a win even if I have no interest in sharing a model between applications.
I don't necessarily have any problems with the persisting (that's how ActiveRecord works out of the box), but I'm not sure about the displaying, because I sometimes want to display things differently depending on the context.
Likewise if you want a separate Displaythingie that can work out how to display an account or a customer on its own, great. If it needs to know a lot about accounst and custoemrs to do its job, but you want to swap it out or paramaterize it (e.g. one set of views for iPhone, one set for Safari), the classic organization makes a certain amount of sense.
All that being said, I have built a large, public-facing app with multiple views for multiple devices, and my experience is still that we did modifications across all of the things related to a model much more often than doing modifications to all of the views across all of the application.
There are plenty of architectures where "data objects" are dumb and are passed to more intelligent objects that can save them, serialize them, etc.
MMM|VVV|CCC is a better system than MVC|MVC|MVC because it encourages separation of concerns, and loose coupling between concerns. Tight coupling between mostly unrelated pieces of functionality (why should the persistence code know anything about the controller?) is a very nasty code smell.
They don't know anything about each other. The question is not whether M,V, and C should be the same entity. The question is why they are scattered all over an application, such that adding a single field to a model involves going to one place to add a migration, another place to add validations and other model logic, a third place to change controller logic, a fourth place to change one or more views, and so forth.
Should they be separate files? Perhaps yes. Should they be far away from each other? That is what I am questioning. The "Separation of Concerns" you are describing is not a very persuasive argument in Rails apps, IMO, because I often have a concern like "add a field to this model" and I rarely have a concern like "Change from HTML 4.0 to XHTML" or "Add a created_at column to all tables."
Separation of concerns aims to produce modular, loosely coupled code.
Now, if we start from the point of view that they should be in separate files anyway (in the ruby way, each file should contain one class rather than many - and I don't think it's helpful to change that), then I don't see what difference it makes whether the files are in the same directory or in separate directories.
If you have any sort of decent editor, opening the file you seek should be a matter of pressing a shortcut and typing part of the filename... Certainly, I rarely use the mouse to open files - except when i'm browsing through a new project, but that's a fairly rare use case.
Now, there's another problem I can see with your proposed organisation: although in some cases (even many) applications are built around resource objects, almost every non-trivial application has many edge cases of functionalities that are not directly attached to objects, or are attached to multiple kinds of objects, or are attached to objects but in a way that could be mapped to one object or to another, and is actually best thought of as being linked to something else.
Forcing the file system to be organised around resources like users, projects, items, etc would coerce us into trying to fit functions onto specific objects - and, importantly, it would remove the flexibility of being able to not tie a function to an object.
As such, I think the current model is more flexible and offers something that your proposed model doesn't support and which is useful on most projects.
etc. I think it does indeed make more sense. Though the difference is not that big except for one case: Reusability of the code, that way you can easily just copy the directory to another site.
That way you can focus on the domain objects as data, and how they are related to each other. You can also come up with cleaner (and more orthogonal) patterns of how to display, persist, or otherwise handle that data.
PAC : http://en.wikipedia.org/wiki/Presentation-abstraction-contro...
HMVC : http://www.javaworld.com/javaworld/jw-07-2000/jw-0721-hmvc.h...
If you can handle a larger number of classes you can sort of get around the question by using a good plugin loader that can associate the proper Persistamajig or Displayamajig with a particular object at run time.