I'm perplexed to understand what you are hoping to achieve here.

First you say:

Lamentably, another team had already written a truly horrible Windows .BAT script to do just this. Since I find it intolerable to maintain code in a language lacking subroutines, local variables, and data structures, I naturally started by re-writing it in Perl.

Great! You're going to replace the severely limited batch language with the power of a proper programming language.

But then, you decide:

To allow my script to be used by other teams, and by non-programmers, I need to make it easier to specify different action tables without touching the code.

And so opt to make your script data driven; with the result that:

Another concern is that when you have thousands of actions, or thousands of tests, a lot of repetition creeps into the data files. Now dealing with repetition (DRY) in a programming language is trivial -- just use a function or a variable, say -- but what is the best way of dealing with unwanted repetition in XML, JSON and YAML data files?

And so you come full circle and ended up with mechanism that has less flexibility, power and control than the batch script you started with. The link you provided lists AWK & sed as the other examples of data-driven programming; and Perl was designed to replace them.

And to what end?

I find the idea that non-programmers are going to be designing/configuring builds and tests of production application software totally untenable; akin to asking a non-musician to conduct the orchestra rehearsals.

Seems to me that you've lost sight of what your trying to achieve and been deceived by a new buzzword for an old idea.

Even the data formats you've suggested are a) overkill; b) require a programmer's understanding of the format to use. You mentioned liking "table-driven", so why are you looking at hierarchal data formats instead of a simple table of CSV data?

My take would be to step back. Look at a few examples of actual use cases and look for the simplest solution to solving those use cases; rather than trying to invent something that is all things to all possibilities.