It is indeed possible that there is a philosophical gulf. However, it is also possible that engineers who dislike Bazel (and love things like Make and CMake) haven't worked in large, multi-language organizations.
I'm not aware of the author's history, so I don't want to imply they haven't, I'm saying generally.
Bazel is a tool that exists to solve specific problems. And it (and clones) does that miles better than any tool out there.
1. Caching, while maintaining hermeticity and correct dependency tracking.
2. Remote execution - yes, contrary to the author's general focus on small, specialized, C (or similar) tools, products out there have to deal with thousands of dependencies that take forever to build and are nice to offload to a beefy server. They also need to support several different devices and architectures.
3. Actually being able to run tests, use the same caching mechanism on tests, surface those results to CI.
4. Being able to plug in arbitrary languages into the build system, with a sane (subset of Python) DSL to write rules in. Because not every project is written in C/C++, or in a single language.
5. Having very clear separation of build phases so you can't shoot yourself in the foot.
6. A lot of hooks to provide better integration with CI, as well as to collect profiling info from your end users, so you can actually make life better for your engineering org as a member of the developer tools/infrastructure team.
In general, my gripe with Bazel complainers is there is a loud community of them on the Internet whose primary software engineering experience is either in languages that build fast, projects that are small and with few dependencies, or just have a small number of people.
There is a world of software out there beyond the Web and C UNIX utilities. Try doing any high end computer vision, robotics or HPC work and you've to deal with a bunch of dependencies trying to solve very complicated problems. One can discuss whether some of those dependencies are well designed or not, but at the end of the day they are very good at their job and don't have much competition.
Bazel solves a lot of problems for a lot of these people, so calling it "questionable" is quite ignorant.
I have worked with Bazel, in a large, multi-language organization, but most of these points are solving the wrong problem. Often I argue for questioning the problems rather than taking them at face value and building an unnecessarily complex solution. Bazel is designed for managing complexity - and adding tons more in the process - while the right solution is to reduce complexity.
> I disagree, and there is a huge philosophical gulf of understanding between my view and those who feel differently.
Let me ask you two simple questions:
1. I work on a project in a git repo and do a git pull to get the latest changes to the branch. I do the equivalent of `make` with my build system, and encounter a problem (either a build error, or some unexpected bad behavior from the built artifact). Should I be allowed to conclude that someone has messed up, or do I first have to engage in some gyrations to make sure I have a "clean` build and the correct dependencies (git clean -dxf, issue commands to manually check and update dependencies etc.)?
2. I push some code after running the equivalent of `make test`, which passes successfully. A collaborator informs me that after pulling their build is broken or there is some unexpected failure, which does not appear to be a flake. Should I just expect this to happen every now and then and live with it?
If your answer to 1. is "No" and your answer to 2. is "Yes" than there may indeed be a gulf of understanding, but probably not a "philosophical" one. If your answers are "Yes" and "No" respectively, then I'd certainly love to hear what philosophical more aligned general purpose build tools have this property, because I'd be interested in investigating them. The only other tools in this space that I'm currently aware of of even making an attempt in this direction are either different granularity (nix) or unreleased/more of an academic POC (redo/shake).
I disagree, and there is a huge philosophical gulf of understanding between my view and those who feel differently.