Forgive me if I'm misunderstanding the vulnerability, but isn't this one of Raymond Chen's "It rather involved being on the other side of this airtight hatchway" exploits? That is, any commands you run has the same permissions as you have.
Now, I understand that you may not intimately understand 100% the code of the commands and shell extensions you use, but is that a "vulnerability"?
The privilege escalation is from "can push code to a repository that you pull from" to "can run code as you". The idea is that you trust the shell extension you're using, but a particular git repo exploits a vulnerability in that shell extension.
git cloning code vs. running code is sometimes a security boundary and sometimes not. For instance, if you go cd into that directory and then run make or ./configure or ./setup.py install or docker run or something, then yeah, you've removed that boundary. But in general, it's reasonable to keep the boundary there. Perhaps you're doing code review of code by an untrusted author, either of someone else's project or of a pull request to your own project. Perhaps you're packaging up the software to run it as a less-privileged account. Perhaps you're a sysadmin helping a user figure something out. And so forth.
It wouldn't even require an explicit clone. An attacker could send you a zip file containing a malicious .git directory, and then you'd lose the moment you cd'd into the unzipped directory to check it out.
If allows an attacker to execute arbitrary code in a situation where you wouldn't expect that (such as merely CDing to an attacker-controlled directory), then yeah of course it's a vulnerability.
Now, I understand that you may not intimately understand 100% the code of the commands and shell extensions you use, but is that a "vulnerability"?