Experienced Java programmers will most often be indoctrinated/trained/used to over-engineering and wrapping everything in layers upon layers of abstractions. And the existing Java learning books, tutorials and examples still tend to follow that mindset.
The more abstracted your code is, the slower it will run, the more memory it will consume and most especially the more difficult it will be to get a new developer up to speed.
I believe you that there are ineffective programmers of any language who over engineer, but I haven't seen that from personal experience with Java programmers. To the extent that it's a problem, it sounds like a hiring problem rather than a Java problem.
Being a big company doesn't imply good Java code. Just look at Lotus Notes, SAP, Eclipse, the whole IntelliJ ecosystem... all slow-as-fuck, resource-eating monsters that have fast, non-Java alternatives that prove that the job can be done in "fast and lean" (except SAP, though. But SAP rants, I tend to get carried away in these).
I also don't see tutorials or books that create too many layers for a while (especially post EJB2/EJB3.0 days).