Intelligent caching is also table-stakes though. It requires a detailed dependency graph and change tracking, and that's not something that can simply be relegated to a plugin— it's fundamental.
Right, and I think that's a combination of a few factors— first of all, there's the basic momentum that CMake is widely known and has a huge ecosystem of find modules, so it's a very safe choice— no one got fired for choosing https://boringtechnology.club
But bigger than that is just that a lot of these build system and infrastructure choices are made when a project is small and builds fast anyway. Who cares about incremental builds and aggressive caching when the whole thing is over in two seconds, right? Once a project is big enough that this starts to be a pain point, the build system (especially if it's one like CMake that allows a lot of undisciplined usage) is deeply entrenched and the cost of switching is higher.
Choosing technologies like Nix or Bazel can be seen as excessive upfront complexity or premature optimization, particularly if some or all of the team members would have to actually learn the things— from a manager's point of view, there's the very real risk that your star engineer spends weeks watching tech talks and yak shaving the perfect build setup instead of actually building core parts of the product.
Ultimately, this kind of thing comes back to the importance of competent technical leadership. Infrastructure like build system choice is important enough to be a CTO call, and that person needs to be able to understand the benefits, to weigh activation costs against the 5-10 plan for the product and team, and be able to say "yes, we plan for this thing to be big enough that investing in learning and using good tools right now is worth it" or "no, this is a throwaway prototype to get us to our seed money, avoid any unnecessary scaffolding."
