At the heart of DCI is the cognitive tools it provides the developer. I'm not sure if you've seen all the great James Coplien/Trygve Reenskaug lectures, but I will try to distill the gist of it for anyone new to the concepts. It is about moving system behavior out of the systems' interacting domain objects(data entities, or what the system is), and into behavior objects(what the system does) as first class citizens which mediate the collaboration between objects by injecting them with functionality in the context of a use case just-in-time.
Think BDD. We code the behavior not across many objects like particulates of functionality spread out all over our data objects which are highly coupled to the persistence layer, but within cohesive objects that exist solely for a use case(story), and which inject capabilities into and coordinate the interactions of these dumb data objects. Like sheer layers of a physical architecture, slowly changing data objects are not loaded up with rapidly changing feature implementation that they carry around all the time. Rather, Ruby provides us the ability to easily inject the behavior into the objects at runtime when/if needed only in the context of a use case.
As an example in ROR, if you have a controller action involved in a use case in which there is an event probability matrix where most entries may be triggered in only a small percentage of requests, then instantiating a network of bloated behavior-heavy objects with the knowledge to execute every event for every possible use case of the data is unnecessary. Also, not having to dig through 18 files in my text editor to understand how that interaction works vs. having all the logic cleanly abstracted to patterns in an interface provided by the context object is a definite plus as well.
Regarding your question about 'another' layer of abstraction between controllers and models in rails, I'm not sure which other one your referring to. Regardless, Yes. By all means. No problem. Design patterns and Uncle Bobs' SOLID principles are pretty much generally accepted best practices in OO design. Both of these strongly encourage loosely coupled abstractions between policy and implementation. They both help avoid catostrophic brain dumps of roman empire demolishing magnitude, because they provide a common framework everyone understands. DCI, for me, provides the same type of cognitive framework, but for making a system easier to comprehend and deal with effectively, and this is the holy grail for any object oriented designer.
