Since I added Hibernate support to CF Groovy, I've been using that for pretty much all new development. Oh, how nice it is. The perm-gen issue is still lingering, but if after a few projects, I've realized that you don't actually end up touching your persistent entities that much, so it's not as big a deal as it seemed it would be. Most of the work on those is done up front, laying out properties, relationships, and various helper methods and psuedo-properties.
Yes, my apps suffer from what Fowler has dubbed an "anemic business model", but I don't have great issue with that. It's a concious design decision, not an anti-pattern that has cropped up without my knowing. It's specifically driven by the non-CFML nature of the persistent entities, and as such they're not really full-fledged business objects. Instead, they're more just value objects (or data transfer objects) both inside the app and between the app and the database. I'm also a big fan of simple, and while I'm definitely not following the all powerful "best practices", I tend to weight simple as a higher priority than a lot of people.
I've also seen a signficant shift of Groovy code from the service layer up to the web layer, which is something I wasn't expecting. My initial thoughts were that the web layer would stay almost entirely CFML, and the Groovy would be used for the backend code and interfacing with Hibernate. The views are still all CFML, but my controllers are growing Groovy snippets all over the place, while the service layer is mostly just interfacing with CFML APIs from the Hibernate plugin, actually using Groovy for very little.
One little piece that I have't posted yet is a "port" of my TransactionAdvice CFC for use with the Hibernate functionality of CF Groovy. The logic is exactly the same as the original, just no ability to set an isolation, and it requires a reference to the Hibernate plugin instance. Download here: HibernateTransactionAdvice_b4173.zip.