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.
Same thing happened to me. It's rather annoying, since it pollutes the workspace of the promotion.
The problem becomes show stopper when the GIT SCM of the original job uses a specific credential to clone from the repo. The promotion gets the repo information, but not the credential, so the clone fails.