Let me clear it up for you: I’m not trying to advocate the usage of object composition instead of MVC. The real message here is “use what works for you, but, hey, check out this alternative!” While it’s easier to break encapsulation with using this pattern, it’s also possible to have a maintainable application as you mentioned.
If you are dealing with a Rails app, for instance, there’s no reason to apply this technique instead of MVC. And even if you go that route somewhere else (where MVC is not the golden path,) you can still apply the same ole design patterns and best practices.
That said, I disagree that object composition (instead of MVC) makes the code unmaintainable for more complex solutions. It’s quite the opposite if done right: you will get a better overview of what your code does with less effort. Controllers and views will still be there somehow, but in a different, more flexible/composable incarnation. It’s all about maintainability.
About Rails, yes: there’s some value in having “controller”, “models”, and “views” folders when a project is just starting, but in my personal experience this convention becomes a bottleneck the more the project grows. When the project reaches a certain size, I’m much more interested in easy domain and feature discovery — which means having cohesive namespacing and focused objects that do one thing only. Fortunately, tools like “concepts” (from Trailblazer) help on solving this problem in Rails apps.
By the way, I enjoy something along the lines of DDD (domain driven design), so check it out if you haven’t already :)
To sum it up, the main point of this post was to cover something about object composition (in or out of MVC), which I think is a killer technique. Finally, it’s possible to be “organized” with either approach, as long as you have good conventions!