To the creator of these tools: Try to remember that what you are creating is a support tool. A second act to the main development language. It is better if it is not general purpose, it is better if it is not turing complete, it is better if it is less powerful.
A programming tool has a certain affordance. It talks to the programmer and says "hey - here is how you use me".
Maven says: Hello. I am a just a configuration file. Just put your project's name and the dependencies in here and the defaults will take of the rest. You remember Ant? Please don't turn this into a big mess.
Gradle says: Oi buddy. I am a full-fledged scripting language. Anything Maven can do? I can do the same times 10. Plus my syntax is tight - just look at this &#€#"&/+=+++ << '${.&%&}' ... Not even a semi-colon.
You see the cool kids over there? They all have advanced build scripts with code generation, variable substitution, dsls, database migration, performance daemons. You need this too (unless you are one of those corporate XML-dorks ... yuck XML, it sucks, no one uses XML anymore).
And because we are so cool, we change all the time so you better keep these random files we generate for you under version control: gradle/*, gradlew, gradlew.bat besides your actual build script.
Regarding the execution speed, IDEs not able to autocomplete, no guarantees about the format that IDEs can easily parse, and it often breaks between releases.
Then to compensate for lack of speed, you need to have a running daemon and an in-memory build cache.
If you wrote a custom gradle build script (or indeed, any other custom scripts), then you cannot be sure when that generation of sources is going to happen.
Maven forcing you to design your build around maven's fairly strict set of phases (and build lifecycle) means you confirm, and any tooling can compose as long as they also conform.