I'm of the opinion that the world was a better place with Ant and when we had third party dependencies manually, deliberately adn deliberatively managed by hand in /jars/thirdparty
As someone that was writing Ant scripts when CruiseControl was modern, and there was no Ivy in sight, not sure if it was such a better place.
I hated Maven at the beggining, exactly because we got some hipster company pushing for it during Maven early days, it was still hot out of the oven.
20 years later, I don't see a reason to use anything else other than Maven.
I've looked at it also. The problem is incentives. Will developers pay for a better build system? Probably not. Then, what people use is whatever happened to be given away for free first.
Another problem with shifting Gradle is that lots of libraries now come with build system plugins too, so you'd need to replicate all that logic into whatever new build system you create. And it's actually not easy to get everyone to agree on what they don't like about Gradle. Say "imperative not declarative" and half of devs will agree and the other half will say, no, you need programmatic configuration because build systems are genuinely complex. Etc.
https://gradle.github.io/declarative-gradle/
Fingers crossed.
The biggest problem with Gradle is not Kotlin or even Groovy syntax. Kotlin isn't a bad language to use even for writing configuration. It's that the entire thing is designed in extremely confusing ways from back to front, and has a lot of awkward design choices and bugs that result in a hyper-complex user model.
What the JVM world needs is a totally new tool that has the same feature set as Gradle but with a drastically simpler mental model behind it. The only real contender right now is Bazel, I think.
Android started being devleoped mostly by C++ refugees, that is why originally all framework code is full of m_ prefixes.
Then the whole standard library fragmentation that persists to this day.
Despite the whole excuse why Dalvik was created, Nokia and Sony-Ericson had quite good JVM implentations for Symbian.
When Kotlin was introduced they stiffled Java on purpose, left it on Java 8, using Java 8 examples to promote Kotlin, and have since Android 12, started to finally update ART to more modern versions, because as it turns out, even with Kotlin, loosing compatibility with the Maven Central ecossytem isn't that great.
Still, it is mostly Java 17, and all the ongoing improvement in Java land across all JVM vendors, will most likely never land on Android.
Android is not Java, even though it relies heavily on the ecosystem for its tooling.
Android is basically Google's .NET, and Kotlin plays the same role as C# in relation to Microsoft's J++, that lead to Sun's lawsuit.