Due to the hack in ArgumentsActionImpl.SAFE_ENVIRONMENT_VARIABLES which tries to guess which things are secrets but does not really know.
What I recommended to svanoort when he initially wrote this code was that we should rather get some coöperation from plugins which define secret environment variables. For freestyle projects we have getSensitiveBuildVariables but there is no Pipeline equivalent; and EnvVars has no way of marking secret values.
One option would be to introduce a new API into core and have credentials-binding, mask-passwords, and workflow-cps all depend on it. This would be probably be some more structure in EnvVars, with the various merging/appending methods updated accordingly.
Or, an explicit contextual object representing a Set<String> of secret variable names could be introduced into workflow-step-api, a lightweight dependency that credentials-binding already has. This would be trickier to use from mask-passwords, however, since MaskPasswordsBuildWrapper could no longer be a SimpleBuildWrapper—it would need to be split into a distinct Step.
The least intrusive approach, at the expense of compile-time safety, would be to adopt a simple convention along the same lines as PATH+STUFF=/opt/stuff/bin. For example, if CredentialsBindingStep is defining USRPWD=s3cr3t, it should also define something like SECRET+USRPWD=true. Both variables would propagate through to nested scopes in the usual way, and then ArgumentsActionImpl could tell for sure that it should mask s3cr3t because it sees the environment variable SECRET+USRPWD.