> You can't even figure out what the dependencies are going to be for some Gradle projects without executing them
This sounds like an issue of Gradle, not of programmable configs in general.
Not every config file needs that, but a config file for a build system definitely needs that. Otherwise your build system becomes too restricted and you must either write your logic in plugins or use another scripts along with your main build tool. Both options are bad.
I'm not even sure that build.gradle should be called a config file. It's a build script.
Originally, the whole point of using configuration files for builds was to eliminate the programmatic element where you used lots of little scripts to run builds. Config files are easy to read and reason about.
> Programmatic configuration allows e.g. specify some library version once (e.g. springVersion) and use it for 10 dependencies as a variable
Declarative syntax can also include variables which can't be reassigned to later.
Gradle's original marketing message was based around its syntax, i.e. Apache Groovy being easier to read than XML, which is true. But providing the programmatic ability of Groovy as well is a step backwards for configuration best practice, ultimately resulting in an increase in technical debt. Thankfully, almost all the Gradle build scripts out there are simple 20-liners which don't use programmatic logic.
Gradle ought to follow the example of Jenkins pipelines, which later provided a Declarative Syntax as an alternative to Groovy to mitigate this very issue.
For the same reason that I would want to figure out if my script type-checks without executing it - making it easier to avoid bugs and reason about the program.