This also breaks promotion if the Git config uses variables defined at runtime, e.g. some of our build jobs set the repository using an environment variable (via env-inject) or input parameter. These aren't available to the promotion, and so the clone fails.
I think this new behavior is only useful in the specific scenario outlined in JENKINS-13751 and JENKINS-12659, i.e. you want to control tag creation via a promotion process. This doesn't seem like it would be a common scenario, so in my opinion it would be better if it was not the default behavior; in other scenarios, having the git overhead is not helpful at all and introduces new opportunities for failure.