In short, ambient authority strikes again. Environment variables were a terrible design mistake in UNIX.
It doesn't stop me from supporting it as a deployment process, but there's a 22 year old inside of me that cries a little every time I talk about using environment variables for config.
"Sanitize your inputs!" is the security equivalent of abstinence-only sex education. Yes, it technically will fix the problem if executed perfectly, but an endless history of failure should have convinced everyone by now that it is not the right solution for the real world. As other commenters have pointed out, shells were never designed with adversarial input in mind and so "sanitizing" them means hunting down and endless number of bugs and still not knowing if you've done it correctly.
The correct way is to design from the start so that user input cannot be executed. For SQL, everyone now knows that means parametrized statements; in this case, it means job queues and standalone processes with locked-down privileges.
If getting people to do this is impossible, so is getting people to stop storing passwords in plaintext.
This may very well be the case, though. You may get most people to know that storing passwords in plaintext is not a great idea (tm), but there will always be people ignoring that, be it due to downright ignorance or external factors.
I can envision some non-technical person in an organisation prescribing to IT that a new user password cannot look like one of the user's old passwords, where "look like" actually means something like an edit distance of <=2. Since the secure way of implementing this is looping over all possible passwords close to the one the user entered now, hashing them all and comparing them to a list of past hashes (which is quite resource-intensive, which costs mony), I bet there will be people that will give in and just store the last few passwords in plaintext. Maybe they'll encrypt them, but they'll be there.
Imagine a website that will take an URL and extract the text from it - removing markup - or another service that will scan a URL for meta-tags, etc. All the kind of things that you can find easily.
Now imagine what happens if a user passes input such as "file:////etc/passwd". There are a whole bunch of services which will spit out the contents of the file, because they use some URL-fetching library and don't limit the protocols to http or https.
I wrote a blog-post about that, which was featured here a while back:
Security in depth is hamstrung by an ever-increasing surface area.
I mean, people doing things wrong isn't evidence that they cannot be done right... right?