They are complicated because they do a fuckton of things. Please don't give me another proof-of-concept build system which then turns out to do 5% of what I needa and have no plugins available.
Gradle is fine, just use it. It's not the best. It's OK. If you hate it, use Maven. It's also OK. Just copy-paste some answers off stackoverflow and move on... we'll all be better off.
I recently found out that I can just use Github cli to clone from upstream, and add one line in my game's Gradle build file to tell Gradle to use the cloned folder instead of looking at local cache. In Gradle world it is known as Composite build and, it has really make me like Gradle despite their convoluted build files.
If your build has really custom stuff, and you cannot fit your custom work into those phases (e.g., it interferes with some other custom stuff), then you have a maven problem that's hard to solve. One usually resolve this by writing a maven plugin, and that kinda sucks. But hey, at least if you do it, you can contribute this to the whole plugin ecosystem and thus, improve it for somebody else.
IME the benefits of fixed phases outweigh the costs: any developer can pick up any maven project and immediately know how to build it, how to run the tests, and so on. A lot of other build systems are really bad for knowing where to start; allowing arbitrary task names and arbitrary relationships between what runs when just ends up with projects having pointless differences between what they call things - do I need to run "gradle build", "gradle install", or what? (and similarly for sbt etc.)
That's the biggest problem. Nearly every developer thinks their build has *really* custom stuff whereas it's wrong in 99% of the cases.
Then comes Gradle with its so-much-vaunted flexibility and deliver you exactly what you think you need. And who is going to maintain the clusterfuck of spaghetti code that your build has become?