It should be no scarier than using the eclipse compiler to do the product builds for your java projects. Most of the SpringSource projects build using the eclipse compiler (they want their product builds to do the same thing as their IDE builds - plus the eclipse compiler has nicer error messages and more configurable warnings).
However, I understand your concern. This is another reason I haven't pushed it. I don't know if I yet want to support the eclipse joint compiler as the suggested batch compiler for joint projects, there are still bugs that need ironing out first. Will it work with Maven and ant? Should do, the eclipse compiler already does - but there likely need to be a few tweaks to ensure .groovy files are picked up and passed through (usage of a new task). Will it work with gradle? no idea, but I can't see why it wouldn't, I just don't know enough about gradle. I don't see a problem with users continuing to work in idea/netbeans if they wish to - the eclipse joint compiler will support a superset of what groovyc joint compilation can handle (eg. cross language @Delegate) - so users of those IDEs won't be able to write code it can't handle. I'm discussing with Graeme possibly changing grails to use it, instead of using groovyc.
Right now the only instructions for batch usage are here:
and they aren't as straightforward as I'd like.
I think of particular interest to you is how it handles Ast transforms, since Spock won't work if they don't work. I will say Ast transforms are not where we focus our efforts on groovy-eclipse - and that is probably a big factor in your concerns (understandably). Maybe I could initially recommend it for batch usage only for users not exploiting some funky transform. 'Supported' transforms would be those built into groovyc, those grails requires, and other well known well tested ones like Spock - if the users stray out of that space we don't recommend the eclipse joint compiler.