As I said in the article, the lack of green threads, lack of value types, and lack of primitive boxing are all things that have gotten in the way of optimizing Bazel to the levels shown by the prototype Go reimplementation. These are all things that you'd expect a systems language to have, and Java did not have them. These are finally materializing now, but it's a little too late.
Then you also have the slow startup time of the JVM plus Bazel's initialization, which leads to a possibly-unnecessary client/server process design. This is more wishy-washy though, as this might be optimizable to levels where the startup time is unnoticeable -- but the fact that it hasn't happened in years means that it might not be an easy thing to do.
FWIW, the client server design is also used in Buck2, but it has other advantages than just startup time, like keeping track of the filesystem with inotify or watchman so that it already has fresh information about the state of the build graph by the time you run `build`.
Then you also have the slow startup time of the JVM plus Bazel's initialization, which leads to a possibly-unnecessary client/server process design. This is more wishy-washy though, as this might be optimizable to levels where the startup time is unnoticeable -- but the fact that it hasn't happened in years means that it might not be an easy thing to do.