For example, have you ever wanted to break a large project up into subcomponents with build-time enforced dependency relationships? This is trivial with gradle but very hard/custom to do using make. gradle is aware at a domain modeling level about components of a project, their dependencies, and the implementation and interface artifacts they generate. I think this is really cool.
Their native support is still evolving, so it probably can't drop-in replace more complex native builds, but a few years ago I had it building a shared c++ codebase for macOS, android-linux, and iOS. I could test the core on macOS locally as its own project. I had google-test built locally and specified as a dependency (a sibling project) rather than prebuilt and plopped in a vendor directory. And the code was mostly free of ifdef android or macos etc. because I could not only enforce separation at a project level, but also easily provide a place for platform specific glue to live (in their own sibling projects). It was really cool and would have been a lot more work without gradle.
Checking versions can be accomplished by using awk or another tool to compare output from $compiler --version.
What am I missing?
If the dependency doesn't conflict, then my package manager takes care of it.
And a lot of Java/Groovy/Scala/Kotlin libs are on Maven Central, but not packaged for let's say CentOS/Ubuntu/Debian/etc. So the package manager for JVM is Ivy (ivy2), or full Maven (which is basically ivy + a task runner).