Groovy 2.0 was only released a few months ago, and isn't production ready. Groovy 2.0 has two jars in it, one with static-compilation and static-inference grafted on, and the other with optimizations for JDK 7's invoke-dynamic bytecode. Programmers
can't use both static-compilation
and invoke-dynamic in the same source file.
Also, both jars seem to have problems. Groovy 2.0.4 was released yesterday only 2 weeks after version 2.0.2 was released "to fix static compilation and type inference problems". Grails 2.2-rc-1 (actually the first beta and not a serious "release candidate" for production use, because the releases called "beta" are really alphas) has only just been released, the first with Groovy 2.x, with only the static-compilation jar from Groovy 2.0.2 bundled, not the invoke-dynamic jar.
The facilities of the invoke-dynamic jar might never be merged into the static-compilation jar. There seems to be some infighting at SpringSource over who's in control of Groovy. Version 2.0.3 was skipped because the P.M. "compiled it on the JDK 6 instead of JDK 7 by mistake", which looks like a political play by Guillaume Laforge, SpringSource's project manager for Groovy, against Jochen Theodorou, their technical lead who's done most of the programming work on Groovy since 2004.
A year ago, Laforge hired another developer, Cedric Champeau, to put static type inference and compilation into Groovy, in order to mitigate a SpringSource business threat by Alex Tkachman's Groovy++, a static-compilation addon to Groovy which has since been abandoned. Groovy++ had to switch from supporting Groovy 1.8 to 1.7 for a while during its development because of compatibility problems in subsequent beta releases of Groovy, which may have been deliberate, and at the very least, Groovy++ served as an "inspiration" for Groovy 2.0's static-compilation jar. It's looking like Theodorou's invoke-dynamic bytecode optimizations aren't being merged into the static-compilation jar because of a power play by Laforge and Champeau who control the static-compilation jar. The project manager is diluting Theodorou's technical importance to Groovy and thus increasing his own influence.
Concerning your benchmarks of Groovy with Java, you left out Scala and Clojure, also popular JVM languages, and you chose an algorithm not used much in business. Both Scala and Clojure have lazy-evaluation in their library lambdas/functions, as will Java 8. Groovy only enables strict evaluation, which slows down many computations used in real business programming scenarios, of which fibonacci isn't one. Lazy-evaluation isn't in the pipeline for Groovy anytime soon. Its "GDK" utility methods were mostly written early on by a programmer without the aptitude for developing anything too complex, such as lambdas with lazy-evaluation. Seems like JDK 8's lambdas, due to ship in about a year, will be the first time Groovy will enable lazily-evaluated computations, long after Scala and Clojure. As for the invoke-dynamic bytecode optimizations being merged into the main jar used by Groovy 2.0 and Grails 2.2, JRuby's long stolen that show. It might never happen with Groovy.
And of course there's no spec for Groovy, unlike Scala's detailed spec or Clojure's function doc-strings. Without a spec, Groovy is still single-platform, unlike Clojure and Scala, and many other JVM languages that began their life somewhere else first.
So I don't think slow adoption by Java shops that were concerned about Groovy's performance is the reason more businesses don't adopt Groovy. It's more likely that the static-compilation code isn't production ready, just laden with problems, political infighting at SpringSource, trailing behind other languages in lazy-evaluation of lambdas (Clojure, Scala) and invoke-dynamic optimizations (JRuby), an informal-only spec that changes between point releases, the names "Groovy" and "G-Strings" evoking drug use and discrimination against female employees, and a general sense by technical managers that there's a price to be paid later down the line if they adopt Groovy.