There's been a lot of discussion in the Rails community and on Hacker News over the last couple of weeks about where business logic belongs in Rails in particular, and MVC in general. There seem to be broadly two camps: DHH's "just put it all in the model" and the "objects should have single concerns" guys. To me though, business logic doesn't belong in MVC at all.
Design patterns are not always, or even often, competitors. Using multiple patterns to architect your application is common and quite sensible. For example, MVC and MVVM are both UI decoupling patterns, but they manage different concerns, and can be used well together. In a rich client framework like .NET's WPF, you end up with a kind of MVVMC setup; a combination of the patterns where the controller treats the V/VM part of MVVM as its view. In a web app it's quite possible to have a 'pure' MVC design on the server side which feeds an MVVM setup on the client, which in turn calls back to the MVC controller.
The patterns are not competitors. Neither of them solve the "full stack", from UI back to persistence. And to get back to the main point, this is the problem with the Rails debate: it tries to use MVC to design the whole stack. This will work for apps where the domain is fairly simple. Some of the models may get a bit messy, but on the whole it'll be fine. But when the domain becomes complex the models becomes unmanageable. And that's where another design pattern comes in: n-tier.
Remember that guy? He's the one who says you should separate your app into logical layers like persistence, business logic and presentation. The full stack MVC approach is trying to put persistence and business logic all into the one "model" concept, whereas really MVC addresses just the presentation layer. If your MVC model isn't simple, it probably needs to be abstracted away until it is. That doesn't necessarily mean services and DTOs, but some form of abstraction is needed.
I'm not a "big architecture" guy by any means. I've seen apps with fairly simple business logic transformed into overly complex beasts as the result of too much separation of concerns (eg. service calls between the presentation tier and the business tier, which always run on the same box). There's a balance that depends in large part on the scale and complexity of what you're creating: sometimes architecture adds unnecessary complexity and indirection; sometimes it provides necessary structure and control.
If it's the opinion of Rails that MVC is an appropriate full stack pattern, then that naturally limits the complexity of the problems you can solve with it before you have to start working against the framework.