That is one of the main criticisms yielded against Maven. It works well if you play strictly by the rule book, but if you need somet5hing more flexible it is going to be painful. I am a bit surprised that you feel restricted. Given your comments I would think deflated would be more appropriate. However, moving on, the mantra with Gradle tends to be that once the build file becomes complex, you might have enough to farm it off to a plugin (or at least to the buildSrc folder). This leads me nicely to your next statement.
This is nothing new to build tools that use an internal DSL (i.e. a DSL based upon a programming language). Cons & SCons had this issue way before Gradle was even an embrio. So do contemporary build tools like Kobalt, Leiningen & SBT. The coice is usually between a restrictive DSL (Make & family, Maven, Ant etc.) or a more flexible one. In both cases, build tools are usually extendable via plugins, but the effort required to extend may vary. Gradle is excellent in the aspect of allowing quick experimentation, only extending later, where as something like Maven always requires one to write the neew plugin from the start, without easy experimenting with the build file. (Well, there a limited possibilities, but not nearly as flexible and quick as in Gradle).
Why was XML chosen as the build script style for both Ant & Maven? Most probably because XML was cool in those days in the Java world. Java pretty much supported XML from the beginning (at least from what I can remember, and not having used Java in the 90s). People understood XML. Wind the years forward and I am not going to give the correct answer here (I’ll leave that to @adammurdoch), but it was a time when Groovy was the most expressive and readable way to script the JVM. (It probably still is, but that is up for debate). Choices are made upon technology available and technology known.
END NOTE: There is a modified joke that goes: There are two kinds of build tools, those that people don’t get used and those that they complain about. The mere fact that opinions are being offered up here, is an indication that Gradle is being used bychoice even though people are finding shortcomings in Gradle that relates to the context they are working in and their own personal preferences (we sometimes refer the the latter as signature skills). ONe should not see Gradle as the end-all build-tool, but merely as an evolution in build-tools. It, with its mates like Kobalt & Leiningen, are a next-generation of build-tools beyond that of Maven. They also allow the software communities of the world to experiment with new ideas and new forms of expression and as such learn new ways of doing things. This will also lead into another generation of build tools, which would probably be here within the next 10 years. Exactly what they will look like we do not know. (If we knew we would already be using them).