I would not recommend Grails at all. First, if for no other reason, it's a bit player, so good luck finding developers, tools, help, and all of the other benefits you get with using a language/framework with a large, thriving community. That alone should be enough to steer you away from using it for enterprise anything.
Aside from that, boolean truths are quirky, to put it kindly.
Null evaluates to false, which is ridiculous and doesn't eliminate the need to check for null, just hides the problem if you forget to do it. This is because groovy uses "null objects." Null objects mean yay! no null pointer exceptions, but the consequence is... no null pointer exceptions! So have fun tracking down bugs when things fail silently.
Variables defined in closures (which is most of them) are opaque, so you can't easily inspect them without printing them out or logging them. So now you have no NPEs and no easy way to check for null values versus empty values while debugging without adding debugging code into production code. Ugh! Don't forget to annotate the debug code so you can remove it when you're done.
You don't get compile-time errors for things like using undefined classes/methods (typos!) or sending the wrong argument types. Instead, you have to compile, run, and look at massive stack traces throwing up all over your console/log: http://pastie.org/583115 Then rinse and repeat until it actually runs. And that's before you even start testing actual functionality.
Method entry and class loading breakpoints aren't supported. (This is simply an inconvenience most of the time, but it's worth noting IMO.)
Conversely, since groovy uses convention over configuration, IDEs may flag things as errors which are not. IntelliJ IDEA probably does the best at handling Groovy/Grails, but it still has some issues. My experience was that Intellisense/autocomplete didn't work reliably for Groovy in any IDE, so if that's important to you, you may miss that.
It's not clear where business logic should go. http://bartling.blogspot.com/2...
It's buggy. https://jira.grails.org/browse...
To be fair, I'm heavily biased against dependency injection, dynamic typing, and coding by convention, which are the very concepts Grails is built around. I could go into all of the reasons, but any flamewar worth its salt will list them all for you.