Grails 3.0 Released and the Road Ahead
grails.io
grails.io
With Grails by comparison you're more likely to find plugins that haven't been updated in years and be constantly fighting dependency conflicts. At least that was my experience.
If you go the Grails route it's also inevitable that you'll need to learn all of the various "layers" underneath Grails nice veneer. E.g. Grails wraps a lot of existing Java technologies which are fairly complex on their own like JEE, JPA, etc. Rails seems to be "shallower" and easier to grok by comparison.
As an aside, I personally love the Groovy language and syntax too, and how easy it is to interop with any java libraries.
Don't get me wrong, if I needed to write a Java-based, user-facing web app, Grails is the first option I would look at. But short of the Java requirement I would choose RoR or even Sails.js (not as mature but rapidly improving it seems.)
We have stopped building new applications/sites in Grails where I work but still have a handful of ones running on 1.x and 2.x still in operation.
If you take something like vert.x in comparison, sure it feels more lightweight unless you need ORM and robust view layer and the things you would need for a front-end framework.
I'm not saying your observation isn't valid, but it feels like a catch-22 in a lot of cases.
Some other devs had taken Django on a tour back in it's 1.1-1.2 days and hated it so I was pushed to look at something else. Did not care for Pyramid and didn't have the time to "do it all" with flask so I settled on web2py.
Turns out to have been a great choice for us so far. The framework is still bloated by comparison, so I don't like it when what we should be building is really an API.
However not having a plugin dictate what version of jQuery I am using has been a boon for fronted productivity.
To more directly address my issue with the plugin system, another commenter said it well "With Grails by comparison you're more likely to find plugins that haven't been updated in years and be constantly fighting dependency conflicts. At least that was my experience."
This mirrors my exact experience on several projects I started and maintained. I just assumed it was because I didn't know how to use grail well. Then I inherited a medium sized code base from some developers who were born and bread java EE devs and _love_ groovy and grails and seemed to always know the "right way."
Only problem was, once I started following the code, it was all just java in groovy syntax and just as crusty and hard to update to new versions.
I eventually gave up following groovy releases and just froze all my projects on the 2.3.x line. I was spending more time every week upgrading plugins and fixing issues that never existed before upgrade (like broken JSON and XML parsing).
When it comes to an ORM, I often just try to avoid it unless I am dealing with an application that has data that I know will be very regular and work well as a spread sheet in a simpler context. Anything more complex and I just research it online or start poking my DBA's for proper design/access patterns. This again leads me to why I like web2py, the DAL is very similar to SQLAlchemy's core design. Just a simple abstraction layer for generating queries and maintaining connections/pooling.
We have talked about vert.x, and it seems promising. My reservation is that I am still not a fan of groovy, Jython is not version 2.7 yet, and I don't know scala or want the verbosity of java. So it just is not my first choice although certainly seems promising.
I am tinkering with flask as well. I don't mind the more DIY approach but having to stitch _so many_ things together just for basic functionality makes me glad I am keeping it for my pluggable API idea which hopefully will replace the DB calls in all our grails applications with API calls to the flask app. But that is another story.
TL;DR
Have yet to settle on a single replacement although web2py is serving nicely at the time being. Our primary concerns are ease of maintenance and number of DB drivers supported which is why Java/groovy based framework seemed to make sense at the time but python based framework and tools make more sense now.
Additionally, Node JS DB support is still pretty iffy, No one here likes using PHP or want's to deploy more of it than they have to, Scala is out because Groovy, C# is already used else where but not the best fit for our web-apps and automation, no one here knows more Ruby than what is required to write Puppet modules, Go isn't bad but can't be used to build a pluggable system AFAIK, one one person knows Perl.