The major point you're making is I should store the settings in a file in source control (VCS) and edit it via just like any other source file. My strong counterargument is that I'm not asking this feature for those kind of settings. I'm asking it for settings that do not belong in source control and need to reside in configuration files located on the build server. I think we can agree that such settings exist or otherwise Jenkins would by default suck all its XML files from some sort of VCS instead of storing them on master's file system.
Think of a job that needs to connect to a custom VCS not supported by a Jenkins plugin. Before a build for this job can retrieve any file from VCS it needs to know connection details to the VCS, settings like a machine name, an URI, a user name, a password, etc. I currently store such settings in a job's SetEnv's config section so that I can see / change them via Jenkins' web ui for job config (I will upgrade to EnvInject eventually anyway but it would be the same thing for the purpose of this example).
The problem I have is that out of ~60 jobs on my build server, only groups of ~5 jobs use the same set of values for the settings I described above. So I'm stuck with choosing to either write those values in a separate file for each group of jobs and store these files on the build server OR copy/paste those values in each job's SetEnv config section.
Either way I have to make an uncomfortable trade off. The copy/paste is terrible because it creates redundant information that is hard to maintain. With files I avoid this problem but I make the setting values obscure because they are not visible in a job's config web ui.
Bottom line is that in this scenario, EnvInject is exactly the same as SetEnv + Envfile and I hoped to get more than the sum of those parts out of EnvInject.
If you still feel the same way I'll accept your resolution and won't argue about this feature anymore.