Measure commits/authors before and after a refactor.
Measuring number of commits? Create fewer, larger commits. Measuring commit size? Pull in more third-party libraries, even where it does't make sense. Author count? Add more/less documentation and recruit or inhibit new devs depending on what your goal is.
Not to mention the number of commits/authors before and after an arbitrary point in time might conflate a successful growing project with a project in a death spiral being passed around from group to group.
It's a good idea, but in practice simple metrics like this often (but not always) devolve into prime examples of Goodhart's law.
If you can’t find a measurable benefit to a refactoring (or anything else, really) then maybe it was not worth doing in the first place.
There is no programming project in existence with enough developers working on it, that developer-productivity data derived from a change to it would not be considered "underpowered" for the sake of proving anything.
A high impact infra change will often inconvenience dozens of people and distract from feature work... You know, the shit people actually care about... (this is analogous to how "Twitter, but written in Golang" appeals to approximately no one.)
And solve the halting problem while you're at it
Goodhart’s law is not applicable to scientific management because metrics have different purpose.