But yes, it’s like a lot of things whose need is born of scale. If you really needed it, it would be obvious to you and if you use it without needing it, it’s going to be painful and difficult to understand.
Everything outside of that use case however it probably isn’t the right choice currently but their stated goal is to eventually become the obvious choice in a lot of other scenarios too.
One big reason is speed: aggressively cached builds are generally much faster. This is very similar to how Turbo gets used in the JS/TS ecosystem, but for many more programming languages. Bazel in particular is very well-supported for transparent remote caching, so your build will often get faster rather than slower as the number of contributors goes up.
Another common reason is that in the presence of more than one or two programming languages, and particularly if one language is furnishing libraries to another, having a unified build rapidly makes it much more manageable to learn one build tool well rather than learn multiple build tools and some orchestration glue on top. A common example here would be the C/C++ extensions that are all but ubiquitous in high-performance numeric and scientific Python applications.
A third example is that C/C++ don’t really have a package manager in the sense that Rust has Cargo. CMake is probably the most popular these days, but it has its own problems and doesn’t interoperate well with other languages.
People seem to like making fun of Bazel et al, and I suppose that’s understandable: it’s difficult to learn and not worth learning until you have the problems it addresses. Add in the default animus for all things FAANG and it’s kind of an easy point to score. But this tendency is what Andre Alexandrescu calls “aggressively intermediate”, when senior people criticize Bazel they do so with valid concrete arguments (and such exist), it’s never “FAANG cargo cult” FUD.
Turbo is popular in the front end for a reason, an imprecise but still useful analogy is that Bazel is “Turbo for backend”.
From what I've read, even for C++ projects Bazel is pushed by FANG-driven cargo cult mixed with FOMO.
Even for its internal use, Bazel sounds an awful lot like a promotion-oriented project.
This is not that different from many other aspects of software engineering, but as on those other areas you need to run a cost-benefit analysis
There's a lot of nice things about bazel like being able to embed optimized JS into an iOS app built from transpiled Java code. But like mdhb points out, if you're not doing a lot of stuff with multiple languages you are probably better off with just that language's recommended build tool.
In another project, I used a hermetic C++ toolchain (you can use gcc with https://github.com/f0rmiga/gcc-toolchain/ or clang/llvm with https://github.com/bazel-contrib/toolchains_llvm) that pulled in its own (locked) version of glibc and lld, etc.
