Well, I think choosing Rails to begin with must be something not done out of the whim. If you pick Rails, then you must love what convention it has already native to the framework. If some people must opt to strip it down further or abstract some logic further away from controllers and models, I honestly think they are doing it wrong.
Maybe start creating their own stripped down version with only their classes involved would be a way to go. Otherwise, maybe they started out wrong by picking Rails for their project requirements. IMHO.
It's all a balancing act. Fat models are harder to test... but having too many models is a mess. So long as a model fits well with general OO/SE principles, like having only one job, it doesn't need to be broken up -- but with a typical Rails app, most of your models immediately have two concerns, their business-logic function and persistence.