Having --indy
by default is on the roadmap for Groovy 3.0 (currently in alpha). The team wanted feedback on the new parser so didn't wait for all features to be available before releasing alpha versions.
The Groovy 3.0 compiler will likely keep a non-indy option of some kind available for a version or two to assist people wanting to recompile old libraries and produce like-for-like bytecode.
Currently, there are some primitive handling optimisations in play when producing non-indy bytecode. Very early benchmarks (on quite old JVMs now) showed some performance regressions since the indy bytecode didn't have those same optimisations. Also on the roadmap for 3.0 is to re-look at performance in those specific cases with a view to considering possible optimisations if still needed.
Exact specifics of whether some non-indy jars will be required for a version or two depend on some other parallel changes to remove some legacy classes that aren't really needed for the indy case but which would be required for all existing libraries written in Groovy to run. That will be detailed in the documentation and release notes once finalised.
There are some more details in [1].
[1] http://groovy.markmail.org/thread/yxeflplf5sr2wfqp