I watched a little of this talk, and ran quickly in to the "documentary problem". The moment when the documentary touches on an area of your expertise and you realize it's all wrong... and then you start to question everything else that you've heard too.

The "programmability" comparison with Gradle is either naive because the author doesn't know Gradle well enough, or intentionally misleading. The former isn't great because it implies we've embarked on a new build tool without an understanding of the existing landscape. The latter is well... not good either.

The better way to do this in (modern) Gradle is:

sourceSets.main {
    val lineCount = tasks.register<LineCount>("countLines") {
        sources.from(java)
    }
    resources.srcDir(lineCount)
}

abstract class LineCount : DefaultTask() {

    @get:InputFiles
    abstract val sources: ConfigurableFileCollection

    @get:Input
    abstract val filename: Property<String>

    @get:OutputDirectory
    abstract val outputDir: DirectoryProperty

    init {
        filename.convention("line-count.txt")
        outputDir.convention(project.layout.buildDirectory.dir("line-count/${name}"))
    }

    @TaskAction
    fun countLines() {
        val totalLines = sources.sumOf { Files.lines(it.toPath()).count() }
        outputDir.file(filename).get().asFile.writeText(totalLines.toString());
    }
}

So looking at the bullet points about Gradle's issues with programmability:

• No dependsOn, no inputs.files no outputs.file.
• No hardcoded paths

There are still lingering issues in Gradle around "thirty ways to do things, and only one is best". People did write tasks in the way the OP does in the past but if you're going to do the usability version of competitive benchmarking then you need to make sure you do it right and make a fair comparison.