Totally agree on this point. Why learn all the quirks of the CMake language just to express the structure of my program?
As to "why learn all the quirks of CMake," the selling points of CMake are its widespread availability, maturity, and coverage. For example, just on the packaging side, it knows how to create tarballs, .debs, .rpms, Windows .msi files, multiple flavors of Mac installers...
Less mature build tools require you to implement this stuff manually. CMake mostly handles it for you (and has the scars to prove it).
All those actions can be easily modeled in a libraries coupled with a DSL.
It has enabled Cargo use its own package ecosystem at build time as well, so build scripts can easily reuse other crates instead of reinventing the wheel for each project.
It also saved Cargo from needing to be a build system that works with everything and supports everyone (the midlayer mistake[1]) and instead 3rd party build-time crates and *-sys library wrappers provide the flexibility.
Python uses a Python script as the main entry point to the package, and it's commonly problematic as doing all kinds of weird shit so your package builds (on your machines, until you change your configuration) is a smaller step than looking up what the system already provides, and thus the default. It also makes static package in(tro)spection much more difficult.
I get the feeling that they're making the exact same mistake that Cabal/cabal-install did in the Haskell world[1] -- they just don't have complex-enough builds and/or a big enough ecosystem yet to know it.
(In Cabal/cabal-install there's a "Custom" build type where "anything goes". Unfortunately that means that it's basically impossible for any higher-level tooling to have any idea of what's going on in the build... and hence it thus powerless to introspect anything useful. It's a huge pain.)
[1] Not that I blame them, it's just such a tempting thing to do rather than completely redesigning the build system to accomodate everything and provide enough introspection/metadata. So it goes, I guess...
(AFAIUI Cabal:Custom had exactly the same reasoning, btw. "It's too difficult! Let's just give up and allow anything.")
It might be a practical reality that this is just unavoidable if you want to achieve success, but at a meta-level I think deserves thinking about whether builds should actually be allowed the full Turing Complete treatment. At least, theoretically: As long as we continue 'allowing' Custom for practical reasons and without serious thought, there can be no progress.
(Btw, I'm quite mad which it comes to this type of thing. I spend way too much time thinking about build systems, etc.)
EDIT: This problem manifests EVERYWHERE: Docker builds randomly guess wrong about whether inputs have changed, cabal-install gets it wrong, SBT/Zinc doesn't quite track dependencies correctly, etc. etc. and it's infuriating.
There has been some discussion about making things more declarative, if this is ultimately the right approach, etc. But you have to do something before you can know for sure what the problem space entails.
In our case, one of the largest uses of build.rs is to link to things written in C and C++; there's no unified tooling there, so if you wanted to make some sort of DSL to handle this, you'd have to also solve that problem, which is a huge undertaking.
I am pretty convinced that "we" (as an industry) already actually know 95% of what the 'problem space' of a build system is, but everybody just wants to greenfield and try to do their own. Why? Because it's more fun! There's no actual real rationale for reinventing everything every few years. I guess it comes about from a lack of attention to history and a lack of attention to the state of the art, e.g. Shake in Haskell-land.
Sorry to be so negative. I'm sure that Cargo at least works really well according to the 80-20 rule :).