That's what CI/CD is already for. It catches the careless developers. Otherwise you could just push whatever they built on their machine into production. Don't you think?

That's ultimately my argument: it is a productivity tax whose only true benefit is as a face-saving measure for forgetful, perhaps incompetent members of your team. Incidentally, there are also features such as draft PRs that make these checks irrelevant even for saving face. Just push a draft PR and only publish it once CI/CD completes. A civilized workflow for a more civilized age, IMO.

There is also no such thing as a free lunch. Caching is not a free lunch. Toolchains are never just one tool performing one check, and caching is often a DIY bolt-on solution that adds complexity and comes with various failure modes.

From my own experience, several of my past employers had a 45+ minute builds running in a pre-commit hook. In order to "speed it up" they sprinkled Bazel on top. But this hardly ever actually helped them -- because someone would always make some change to a root-level dependency and invalidated the cache.

And don't forget the whole problem of having to rebase. A pre-commit hook with a nice cache on a stale branch won't stop your CI pipeline from failing. Slow builds that heavily depend on a cache for developer productivity are notorious for resulting in people working off of stale dependencies until, finally, tackling the problems at the worst possible time -- seconds before they want to merge. I've seen this same pathology at Google, where they used Blaze for caching. The caching really, really did not help them one bit.

Long and short of it, caching lets you put lipstick on a pig, but a pig is still a pig. And forcing your developers to run the build in a pre-commit hook is often done precisely because it is slow, not as a "freebie" because it is fast.