Yes, verbosity is exactly the point. In the comments section, somebody actually wrote it.
Except that empirical evidence says it is a big deal: code size is the best measure of complexity we have, and error rates grow superlinearly with it.
It's interesting how nearly everyone in the software profession pooh-poohs that finding. What we "know" (i.e., what we're used to) is more important to us than evidence. If we took the evidence seriously, we would work seriously to find ways to make smaller systems.
Is it verbosity that is the best measure of complexity, or is it code size? Yes verbosity leads to more code, but it's not the only thing that does. Operating at the wrong level of abstraction also will, and in a way that makes maintenance extremely difficult.
Unfortunately I've not seen any evidence compares the impact of boilerplate vs duplication.
I don't know of any way to separate these. Look at it this way: to make small systems, we need both powerful languages and good programmers.
If you don't get to choose what language to write in (as is the case on most software projects), it's still better to write less code. But how can we measure the impact of language choice? I don't think we can. You'd have to write the system twice, holding the other variables constant. But writing the system once already changes everything.
I don't disagree with you about the importance of good abstractions for reducing code size. Where we might disagree a bit is on the influence of programming language on what abstractions get created. It's fashionable in the industry to downplay the importance of language (algorithms matter more, libraries matter more, programmers matter more - pretty much everything is supposed to matter more). But I think the language we're writing in influences the kind of thing we write, and thus the kind of thing we think, all the way up to how we conceptualize the problem. Maybe it isn't the strongest influence at any point, yet it's compounded over every decision made in the lifetime of the system. Once a system has passed the embryonic stage, by far the most important factor in how it develops further is how the existing parts already work. Language seems to me deeply involved in conditioning this trajectory - why the system grows this way and not another. Not every idea is equally likely in every medium. I think we see this in the fact that distinct languages give rise to such distinct programming cultures.
As an aside, this is something the typical way of comparing languages -- juxtapose a known algorithm written in X to the same thing written in Y -- fails to address.
I completely agree also that the language can have an impact on the abstractions you choose. Some abstractions are obvious in one language and obscure in another. I wouldn't defend Java against a better example than in the original post, it certainly has its weaknesses. But I find that most examples just show bad Java code, not that Java itself is bad, which is not enlightening and frankly becomes tiresome.
On a related note, I think a lot of people underrate the influence of tools on code quality too. They might complain Java IDEs are a crutch that merely let you work around the language's weaknesses. I think they're a lot more than that -- when I start working in a seriously powerful IDE for the first time I was surprised how much it influenced my coding. Powerful automatic refactoring just makes it so trivial to do the Right Thing (give something a better name, factor out a method, etc). Beforehand I would have said that all you need is discipline to create code of the same quality without the IDE. Now I'd say even discipline and good intentions have their limits.
So, Java programs must be much less buggy than CL programs, because most of the things are already available in well tested, open source libraries, used by millions, and with several version out.
So, a Java programmer gets to write just the domain logic, and not also implement lots of things from scratch because they are not available.
I'd take, say:
2K LOC Java Program + battled tested lib for X feature
over
1K LOC CL Program + 1-2 K LOC custom CL X implementation
Not "by my logic". By an absurd interpolation of my logic to it's far out extreme. It's as if someone points out the existence of gravitational attraction, and someone says "by your logic, everything should be pressed together".
The existence of a huge ecosystem of libs and APIs for major languages, and much less so, for lesser used languages, is not disputable. That people programming in languages with more available libs don't tend/need to reinvent the wheel as much as people programming in languages without, is also a basic observation.
Not to mention that libraries != software.