> painfulness to read (not debug with an IDE, which is easy, but to actually read Java code)
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...
The problem is that there are two major kinds of "reading code".
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.
Verbosity adds noise (redundant information), or information that is usually redundant, so you get used to it, so when you see the ~same pattern again, you skim over the things that you think are the same. But then sometimes it isn't quite the same, because of a bug or because the for loop does a decrement rather than an increment, which is lost on you.
Finding the balance between terseness and having a little bit of redundant information is of course very hard.