When the framework essentially gets out of your way and lets you work with the level that you are interested in at that moment... that's a good framework.
If I'm working Ajax and UI I don't want to be bothered with security, servlets, persistence, or anything else. When I'm working persistence I don't want to be bugged by UI elements. And so on. The idea of "don't bother me with the details" applies to all levels and means different things at different levels. I think the Grails team really understood that (if not explicitly then implicitly).
Grails gets the wonderful benefit of living on a stack where people have sweat the details for years. Yet it still manages to hide those details when they don't matter to the problem you are solving. So Grails has the potential of living in the best of all worlds. And it gets this virtue by way of the Groovy Programming Language.
As Marc Palmer points out there are still holes in the pure play Groovy/Grails space. The Grails community still has a learning curve to get over: what should be pure play Groovy/Grails and what should be hybrid Java/Grails? How ever we answer that it should mean that the framework gets out of the way and lets the developer work directly on the problem at hand.
