Storing secrets elsewhere (for some value of elsewhere that may or may not be better than environment variables) would not have helped this vulnerability: even if the OAuth token were in a file, and it were copied into .git/config, git would still have printed the URL on a failed push.
But storing secrets in environment variables isn't a universally bad thing (which is what I interpret "anti-pattern" to mean). It's a bad thing in certain contexts, including OSes (e.g., AIX and OpenBSD) where environment variables are readable by any local user. But there are certainly uses of it where it's more secure than any alternative (e.g., mosh uses $MOSH_KEY for this and it's pretty sound), and except for the OSes where environment variables are intentionally world-readable, most attacks that would let you read an environment variable would also let you read any other place to store a secret, including a file, a pipe, or a special kernel thing like Linux keyrings.
I think you have some faulty assumptions. Environment variables are not usually disclosed because somebody got shell access.
It's very common to print them out while debugging, but not common to print arbitrary files containing your credentials. I have yet to see phpinfo() print ~/.ssh/id_rsa to the world for example, but I sure have pulled a lot of passwords out of it.
But storing secrets in environment variables isn't a universally bad thing (which is what I interpret "anti-pattern" to mean). It's a bad thing in certain contexts, including OSes (e.g., AIX and OpenBSD) where environment variables are readable by any local user. But there are certainly uses of it where it's more secure than any alternative (e.g., mosh uses $MOSH_KEY for this and it's pretty sound), and except for the OSes where environment variables are intentionally world-readable, most attacks that would let you read an environment variable would also let you read any other place to store a secret, including a file, a pipe, or a special kernel thing like Linux keyrings.