Author doesn't know about https://12factor.net and as another commenter mentioned, probably hasn't deployed something to a 'production' environment (or rather, doesn't know about separation of such environments in the first place).
Having used the profiling tool TAU (subtle dig), I instantly understood what the author is driving at, and I somewhat agree for many use cases. I shouldn't have to fill my dotfiles with 10 new variables just to use a utility.
But I was assigned a task last year to remove configuration from environment variables (for security reasons). I deployed my work to 'production'.
Found this:
https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-...
https://security.stackexchange.com/questions/197784/is-it-un...
strings /proc/*/environ
On Solaris/SunOS, you could use `pargs -e $PID`. And so on.
Having separate UIDs to run your processes A and B under shields either one from peeking at the other's environment, though. UNIX DAC is simple and powerful enough for MOST security concerns, I would argue.
This is completely false in any modern OS. You can only see environment variables of your own processes.
(I wish, it's April 1 after all!)
Tight control of egress network traffic is better but more difficult to implement.
Configuration files are resistant to this as you note, but command-line arguments are not (--password=1234 will show up in ps for everyone).
I think you're wrong about that. The blog post author is also author of Meson, the build system.