Respostas:
Na IMO, a parte mais fraca do Grails foi a falta de funcionalidade de migração do modelo de dados (migrações ala Rails ActiveRecord). Havia alguns plugins de terceiros com diferentes níveis de qualidade, mas nada oficial.
No entanto, acabei de descobrir que o Liquibase foi estendido e transformado no plug-in de migração de banco de dados, e isso parece promissor: http://www.grails.org/plugin/database-migration
No lado positivo, para tudo o que usei o Grails (aplicativos da Web simples a moderadamente complexos), tem sido fantástico. Eu diria que posso obter aproximadamente um aumento de 2x a 3x na produtividade do desenvolvimento em uma pilha MVC Java / Hibernate / Spring / Spring.
A execução dos testes de integração foi lenta, pois o ambiente grails leva tempo para carregar e apenas uma fração desse tempo é necessária para executar o teste. Isso aumentará o tempo de execução quando você estiver desenvolvendo código que grava no banco de dados. O outro problema já foi mencionado por Kaleb em sua resposta (sobre a migração de dados). Também descobri que, sempre que eu estava parado, o número de fóruns em que eu podia obter ajuda era limitado quando comparado à ajuda disponível para hibernação e primavera.
Uma armadilha atual para o uso da estrutura é a sua má integração atual no sistema de construção de gradle. Atualmente, ele usa um plug-in para fazer isso, mas o próprio plug-in rompe com novas versões do grails (como tentei usar e corrigir recentemente). Eles planejam corrigir esse problema na versão futura, tornando gradle parte do sistema de compilação grails (em vez de gant), mas a falta de um sistema de compilação que você possa integrar facilmente é um problema. No entanto, essa armadilha desaparecerá no futuro.
Outra armadilha é a natureza dinâmica da linguagem. Você realmente DEVE escrever testes para tudo. A maioria dos erros no seu código é encontrada em tempo de execução. É realmente uma maneira diferente de pensar sobre um programa. A confiança no compilador para encontrar alguns de seus erros não ocorre com essa estrutura. Não estou dizendo que é ruim, é apenas diferente (e uma armadilha se você não estiver familiarizado).
Eu gosto do conceito de grails / groovy inteiros, embora eu pessoalmente tenha usado mais groovy do que grails, acho que ambos são esplêndidos.
A única desvantagem (na minha experiência pessoal) é o baixo suporte a IDE. Eu pensei (de maneira bastante otimista) que, como o SpringSource tinha uma excelente compilação do Eclipse e apoiava fortemente o Grails, esse seria o caminho a seguir. Os plugins do groovy são difíceis de instalar, o preenchimento de código é complicado (sempre um problema com linguagens dinâmicas, mas a escolha de 60 métodos não é tão útil), a depuração pode ser entediante, pois muitas vezes exige a leitura do código interno do groovy e, na versão mais recente, a instalação do plug-in groovy interrompe o depurador Java!
Atualmente, ele possui suporte duvidoso para classes abstratas. Por exemplo, você não pode vincular uma lista de implementações a uma única List<T>em um objeto de comando. Concedido, isso é principalmente irritante, porque eu estou acostumado a isso vinculando magicamente todo o resto! : D
Geralmente ainda é apenas "verde"; você acaba encontrando pequenas limitações e bugs. Realmente, percorreu um longo caminho em alguns anos.