I did describe my comment as a "nit," and solving it is probably more trouble than it is worth. But since you asked...
I have always found the way that the Node-RED editor handles encrypted data via the "credentials" data type in configuration nodes burdensome to use and error prone. For example, you can only see the cleartext value in the editor while entering it initially. Once saved, editing it requires you to re-enter a value from scratch rather than having the ability to see and edit the existing value. Also, the UX for entering the credentials password when creating or cloning a flow makes it fairly easy to accidentally leave your new flow in a broken state that is annoying to repair from within the editor, itself.
For these reasons, I tend to avoid putting data into credentials fields in configuration nodes but, rather, put sensitive information in global environment variables. So for my use case, relying on the same old credentials data type mechanism for encrypting global variables maintained within the flow misses the mark. Ultimately, this is certainly reflective of personal preference and working style. For those who find the existing "credentials" UX less cumbersome than accessing settings.js in a text editor I am sure that this is a welcome feature.
I would, of course, love to see enhancements to the overall handling of "credentials" in the editor, in which case I would probably migrate to using them more extensively. But then I would have little or no need for global environment variables in the first place. So this new feature does not give me, personally, any increase in value and I will happily stick with my tried-and-true approach of putting environment variable definitions in a module file and importing them into settings.js using
require. Again and as usual, your mileage may vary!
Of course, I do recognise the challenges of enhancing how the credentials UX might work. It would likely require a top-to-bottom, end-to-end revamping of how authentication and authorisation work in the editor as well as how encrypted data is accessed in the flows at runtime, entailing substantial breaking changes.
One way to have addressed this dilemma in this particular case might have been to store global environment variables in a new type of file, distinct from either flows.json or flows_cred.json, and handle its encryption / decryption as a new, special case. Exactly how that special-case encryption might work, I leave as an exercise for the reader...