Coming from a java background to rails I found it entirely refreshing that everything wasn't in a utility class or service. Decomposition of a system using utility classes and services(in the n-tier style) is to make your system more procedural rather than more OO. This article is encouraging more OO patterns, closer in spirit to DDD. The article doesn't actually go into this but all of the techniques described can be used to compose a class so that there is still a single API for each model in your system i.e. the decomposition into policies, decorators, services(of the domain type) etc. can be hidden from the user behind the model api.
That's a good point. It sounds like what you're describing is essentially a Facade. That can be useful if you need coordinated objects to manage complexity, but want to keep it simple for clients to use that part of the application. I sometimes create a Facade for a Ruby module that is a package of fine grained classes.
