The issue is that most people in jvm land are on a closed bubble and haven't seen anything else.
This is true for build systems as is for non OO design for example.
Most simply don't know better and the rest of us are simply stuck.
Ant and then Maven started simple enough but people always find a way to justify adding more stuff.
Gradle already started complex enough and they keep adding more stuff...
The big thing is that many Java builds are not just blobs of binaries crammed together, but also have structure and metadata, sometimes generated on the fly.
Not all Java builds are simply compiles. There are several projects that rely on processing steps during the Java build. EAR files are jars within jars.
Then, of course, there's all of the dependencies.
The modern Maven based repository based dependency manager is a blessing and a curse. Drag and dropping an artifact into your project that inevitably downloads the entirety of the internet. Now you may wish to cull your dependency tree, so that needs to be expressible as well.
The primary benefit of Maven and the pom.xml file is that for a vast majority of applications it just work. Even better, its become a universal "project" format that many IDEs directly support. It well handles "dependency hell" in a cross tool way.
I wish Maven were a bit faster, but, simply, it's as fast as it can be for what it does. A good Ant build just flies, but Ant "doesn't do anything". It's just a bag of steps that it follows (for good and ill), in contrast to Mavens declarative style (for good and ill).
I have no experience with Gradle other than I've never run into enough problems with Maven to justify trying something else. On its surface, it doesn't really appeal to me. I was comfortable with Ant (I have no problem with XML), I'm mostly comfortable with Maven. I've not been unhappy enough with Maven to try and jump back to Ant w/Ivy.
To be blunt, if anything it might be you who live in a closed bubble.
Builds that require ad-hoc functionality is the default. It’s extremely rare that everything fits nicely into “cargo build” or other single language build tools’ model. And while these often have escape hatches, at that point you have to write imperative code with no caching and parallelization that is literally the job of a build tool.
I've been doing jvm apps for almost 20yrs...
What builds need to do and what people made the builds do are completely different things.
I don't remember a single project I was involved in that could not had had a simpler build...
True. In our example we didn’t have to generate online help and pdf manuals from the same asciidoctor sources. But when we chose to, we really needed the customization that cradle offered.
Which are mostly small, isolated library code, whose purpose is to be easily incorporated into larger programs. That’s the 90% easy path of build tools.
What about a large project built over 6 years by 50 people, and that has to use some obscure technology to communicate with company A, and another one that has an idiotic build step?
You have to keep in mind that Gradle Inc. earns money by providing consulting for complex builds. An easy build tool would destroy this business model ;-)
The issue is that most people in jvm land are on a closed bubble and haven't seen anything else. This is true for build systems as is for non OO design for example. Most simply don't know better and the rest of us are simply stuck.
Ant and then Maven started simple enough but people always find a way to justify adding more stuff. Gradle already started complex enough and they keep adding more stuff...