1. Distributing modules with BUILD files makes everything just work
2. You don't think at the level of commands/files, you think at the abstraction of targets. How targets happen in an implementation detail.
3. `select` for varying builds in a sane and readable way
4. Shared cache
5. Distributed build and test runner
6. Query language
7. All builds occur out of tree
8. A language for describing builds that doesn't feel obtuse
And the list keeps going on. A "new make" is not an improvement. It is likely where the world is going to go it just misses out on obvious benefits of other build systems.
Happily, not eveyone thinks this way. That's why there is myriad of safe languages -- from Ruby to Rust -- which replaced C in many areas. Sure, C is still around, but many people prefer to give up some control for lots more safety.
The same logic applies to build systems. Sure, you can use "low-level" build system to hand-write gcc invocation in each project, but a bigger system makes your build files much safer.
This means it cannot enforce pinning-on-a-hash ('hermetic' builds in bazel lingo): if you allow dev team to say `git clone hxxp://whatever/whatever/master` somewhere in the bowels of the build system, they invariably go for it. It's easy, agile and it works (for months if not years).
Result? On a large project, every week you get a build broken by some third-party change. Because make is too capable.