To my surprise it stuck around in Enterprise spaces and I ended up running a team that ported a pretty large-ish Perl project (about 20k lines of Perl) into a piece of Java middleware. I didn't do any of the coding, but I knew the Perl bits inside and out so I knew what kind of testing and performance to expect and getting the Java port up to 1/3rd to 1/2 the performance of the original Perl was a pretty big challenge at the time. This was about...8 year ago. But to the credit of the team and I guess the tooling, they were able to get the port done remarkably quick.
So I've been pretty surprised to see that Java code can get fast, really fast. I've also managed to bang out some pretty slow code if I wasn't paying attention. For my latest touch into it, I ended up spending a week just benchmarking various collections to see how they actually worked under the kind of real-world uses I'd be putting them through (vs. what their big-O sheets claimed) and came away with a set of practices for me to get going with.
I've also had to come to terms with benching code a bunch of times to give the JIT compiler or whatever runs under the hood in the JVM some time to optimize, the first few runs are invariably much slower than run 1000.
This is incredibly important and I never see any Java advocate addressing it. I _do_ see tons of people pointing out how easy it is to automate refactoring, and then they leave dozens of ugly, poorly-thought-out methods lying around...
There's (A) the brief pass you do to get the gist of what a class/method does, and (B) the deeper pass when you try to build a mental model and step through bits of code in your head.
While Java's verbosity does harm skimming, it also aids targeted comprehension, since it is easier to see the "one right behavior" that code has. Fewer sneaky surprises, leaky abstractions, weird type coercions, inferring which class-interface the designer intended to target, etc.
As mentioned already, the other big advantage to explicit-ness is all the static analysis the IDE can do for you.
Finding the balance between terseness and having a little bit of redundant information is of course very hard.
5 years ago those 3 languages were the talk of the town for alternate JVM languages, but things change. Scala's pulled way ahead of the pack, Clojure's consistent, and Groovy's on a downward trajectory, following in Beanshell's and JPython's footsteps. Eclipse users are drifting into Xtend, and IntelliJ users may look at Kotlin more. JDK 8's Nashorn is likely to scoop up those who just want to write quick-n-dirty's manipping Java classes.
Scala is the interesting one I'm interested to see if a simplified type system can be introduced ala http://www.infoq.com/presentations/data-types-issues
Within the Spring Framework 4.0 Reference [1], the Spring Expression Language takes up all of chapter 7, whereas Groovy takes up little section 28.3.3 only, with only one use case presented. Your statement didn't have any specifics, only sales adjectives like "great test frameworks."
[1] http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-frame...