His observations about the usability of Bazel for open source projects are sadly true. When the Bazel team presented bits (it's largely created in Munich!) I also asked if we'd open source the Google runtime that we target internally. It's still different than how Linux distributions work, but at least one would have a hermetic target.
In the end the list of targets is ultimately what configuration decisions need to be based upon. "Ok, this is Linux amd64 with compiler A and libc Y, so let's activate configuration set X that includes feature set Y" is a good specification of a contract that you do not need to re-test with autotools every time you build a binary.
Blaze works as well as it does - for Google, -because there's a single unified codebase with all libraries checked in and few agreed upon and fixed system components. With that, you're correct as well as fast. As soon as you leave that hermetic boundary and try to access system libraries things get very messy.
I can totally see a Java environment with lots of different packages available through BUILD files that can be depended upon. (Probably versioned, so that you don't break builds.) I have a hard time imagining a Linux distribution environment that is similarly accessible to such a new build system.
As for Java used for Bazel: While it's significantly less portable than C, so is Go. Debian's testing approach by throwing so many architectures onto C code to find new exciting bugs is mainly necessary because C is badly specified and every architecture does it differently. If an architecture is actually used, it will have Java. (So does my BluRay player, just sayin'.) And resource consumption mostly depends on the working set you actually need, given that JVMs are heavily optimized these days.