Respuestas:
En mi opinión, la parte más débil de Grails ha sido la falta de funcionalidad de migración del modelo de datos (migraciones de Ala Rails ActiveRecord). Hubo algunos complementos de terceros de diferentes niveles de calidad, pero nada oficial.
Sin embargo, acabo de descubrir que Liquibase se ha extendido y convertido en el complemento de migración de base de datos, y eso parece prometedor: http://www.grails.org/plugin/database-migration
En el lado positivo, para todo lo que he usado Grails (aplicaciones web simples a moderadamente complejas), ha sido en su mayoría fantástico. Yo diría que puedo obtener aproximadamente un aumento de 2x a 3x en la productividad del desarrollo sobre una pila Java / Hibernate / Spring / Spring MVC.
La ejecución de las pruebas de integración fue lenta ya que el entorno de Grails tarda en cargarse y solo se requiere una fracción de ese tiempo para ejecutar la prueba. Esto aumentará el tiempo de respuesta cuando desarrolle código que escriba en la base de datos. El otro problema ya ha sido mencionado por Kaleb en su respuesta (sobre la migración de datos). También descubrí que cada vez que estaba atascado, el número de foros en los que podía obtener ayuda era limitado en comparación con la ayuda disponible para hibernación y primavera.
Un obstáculo actual para usar el marco es su pobre integración actual en el sistema de construcción Gradle. Actualmente utiliza un complemento para lograr esto, pero el complemento en sí rompe con nuevas versiones de griales (como he intentado usar y arreglar recientemente). Planean solucionar este problema en una versión futura haciendo que Gradle sea parte del sistema de compilación de Grails (en lugar de Gant), pero la falta de un sistema de compilación que pueda integrar fácilmente es un problema. Sin embargo, esta trampa desaparecerá en el futuro.
Otro escollo es la naturaleza dinámica del lenguaje. Realmente DEBES escribir pruebas para todo. La mayoría de los errores en su código se encuentran en tiempo de ejecución. Es realmente una forma diferente de pensar sobre un programa. La confianza en el compilador para encontrar algunos de sus errores no ocurre con este marco. No digo que sea malo, es simplemente diferente (y una trampa si no estás familiarizado con eso).
Me gusta todo el concepto de grial / groovy, aunque personalmente he usado más simplemente groovy que grails, creo que ambos son espléndidos.
El único inconveniente (en mi experiencia personal) es el pobre soporte de IDE. Pensé (bastante optimista) que, dado que SpringSource tenía una excelente construcción de Eclipse y apoyaba firmemente a Grails, este sería el camino a seguir. Los complementos groovy son difíciles de instalar, la finalización del código es escasa (siempre es un problema con los lenguajes dinámicos, pero darme una opción de 60 métodos no es tan útil), la depuración puede ser tediosa ya que a menudo requiere pasar por el código interno de groovy, y En la última versión, la instalación del complemento maravilloso rompe el depurador de Java.
Actualmente tiene soporte dudoso para clases abstractas. Por ejemplo, no puede vincular una lista de implementaciones en una sola List<T>en un objeto de comando. De acuerdo, esto es principalmente molesto porque estoy acostumbrado a que mágicamente enlace todo lo demás. :RE
En general, sigue siendo un poco "verde"; eventualmente te encuentras con pequeñas limitaciones e errores extraños. Sin embargo, realmente ha recorrido un largo camino en unos pocos años.