Hermetic is a subset of reproducible builds (bit-identical results). You can have a hermetic build and it calls getrandom() as a side-effect that ends up in the binary.
The only thing that bazel prevents is that your build rules do something like that accidentally, without it being glaringly obvious (eg. accessing $RANDOM, $$, /dev/urandom, time, ... in a shell script)
All of which makes me think that maybe Google's internal building of code isn't that fast. Or perhaps it's fast, but only in relative terms (as in you're still waiting a few minutes for hello world, but huge programs build "fast", as in a few dozen minutes)
I did test it on hello world, and euhm ... It's not fast. The first build of it is horribly slow (double digit minutes, wtf is it doing ?). Second build is "fast" which should be understood to still be double digit seconds. Running the same program in VSCode and just compiling it with the system-installed compiler is so fast you see the output before the VSCode has finished drawing the terminal window.
Reading the site I also get the impression that Bazel's singular focus is correctness. They don't mind things being ridiculously slow if it increases the odds of being a correct build.
I've spent a few hundred hours integrating bits of CMake build scripts in to various Bazel builds.
If you're doing something which is explicitly catered for by Bazel itself then it works well, so long as you avoid the bugs.
Otherwise, you'll have to confront the hermetic build abstractions which prevent otherwise simple operations. Bazel toolchain files are just as bad as CMake, if not worse.
I'll give Bazel another try in a few years. For now, I still prefer CMake+Ninja, worts and all.