True. Gradle (and its Apache Groovy build DSL) conquered a market by first creating that market. There's really no need for a build system with a procedural build language -- a declarative language to describe a build like with Make and Ant/Maven is good enough.
I don't know, Gradle allowing easy extensions allowed us to do continious delivery significantly easier than with Maven (not to mention iOS build system). It's not a must, but it's a really nice thing to have when you need to build several versions of a build, tag versions dynamically, build docs, etc.
so, they addressed that pain point by using Gradle, which also did dependency management really well (compared to say Ant and, many would argue, Maven) and by incorporating/integrating the Gradle Android plugin with the intelliJ IDE.
Instead someone at Googleplex managed to steer a team to rebuild the world to their favourite IDE and in the process reboot the whole Android development stack, which by the way is still not done.
Oh, and the NDK support was in limbo until Jetbrains released CLion. Had CLion not been released and to this day there wouldn't be a solution how to use the NDK inside Studio.
I bet Google IO 2018 will again have a talk about how to improve Android build speeds.
Indexing that one cannot turn off unless laptop mode is enabled, spinning the HDD all the time, really?
Also none of our customers IT teams allows InteliJ on their leased hardware/VMs to external partners.
The exception being Android Studio.