Yeah, bazel is sort of the exception that proves the rule, here. I wish it did not have such an absurd learning curve; I've found it next to impossible to get started with it.
Bazel is weird. I work at Google, and it's fundamental to our engineering, and I love it for that, but to me it's an internal tool. Nearly all Bazel code I work with is internal (most open source uses of it I see aren't doing enough customisation to be worth it in my opinion), it integrates into so many parts of our engineering workflow, and uses so many internal services like our build farm.
I'm not sure I see much point in using it outside of Google. Maybe if you're a company within 1/10th the size and have a lot of Xooglers? It seems like the sort of thing where most companies don't need it and therefore shouldn't use it, and those that do need it probably need to build their own that's right for them.
It worked well enough for my last company. It does require a team to teach it and to do the heavy lifting on custom rules and tooling. I'd rather do that than worry about whether my c++ that was exposing me to millions/billions of risk might have skipped some tests in our haste for an intraday release.
Not only is it hard to get started with Bazel, it's hard to continue with Bazel even once you do. Unless you are using Google practices (say, vendoring and compiling all dependencies), you will certainly end up mired in poorly-maintained third-party tools that will cause no end of fun side-quests.
My work became a lot more, ahem, linear, once I moved us off of Bazel.
I'm not sure I see much point in using it outside of Google. Maybe if you're a company within 1/10th the size and have a lot of Xooglers? It seems like the sort of thing where most companies don't need it and therefore shouldn't use it, and those that do need it probably need to build their own that's right for them.