At the moment, the revert ordering from this tool is unspecified (though it happens to be in git log order, so newest reverts come first).
From the standpoint of tooling and users, this seems to be the opposite of what we want by default: tools and users will generally try to apply these reverts as cherry-picks. If two reverts in the list are close enough to each other, if the reverts get applied out of order, we'll get a merge conflict.
Rather than having reverses for most tools (and mental reverses for manual users), just guarantee an oldest-first output ordering for this function.