Actually, I would say that the very first example is the correct organisation with proper separation of concerns. The reason they are often merged into the form of the second code sample is for convenience rather than for organisation. From a code design perspective, this is not a good thing (and I know many people who complain that Rails made a mistake with that). From a testing perspective, for instance, the coupling between the User object, the methods that save and load that object from the db, and the validation code, make it much harder to write cleanly isolated tests.
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.
> why should the persistence code know anything about the controller?
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.
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.