Couple of things here.
Firstly, environment variables are not "Secure" (capital S) - in the sense that they exist in a server memory space that is actually quite easy to access (which is why Node.js has a library that lets to access them very easily). So while many people and websites that should know better present them as a security feature, they really aren't.
However, they can be better than storing them in an unencrypted file in the sense that it can be marginally harder for an attacker to discover them.
Secondly, when using a .env file, you need to make absolutely certain that the user id running node-red (or any other daemon code other than systemd) cannot access the file. For example, if you make the file owned by root, systemd will be able to access it at boot time but your nodered user will not - AS LONG AS, you aren't foolish enough to run Node-RED as root (which I know, no matter how often we tell people not to, some still do) or to put the nodered user into the admin or other privalaged group.
Lastly, the best way to secure sensitive access keys is in an HSM (Hardware Security Module). 2nd best is to use the software-equivalent, a keystore. You will need a mechanism to retrieve the appropriate key value at node-red startup time of course and then you are back to the original issue - assuming that Node-RED runs all the time, the key will be in an in-memory environment variable. A better solution would be a custom node that reads the key value from the keystore only when it is needed and deliberately removes it from memory straight afterwards.
Having said all that, much of this is severe overkill for many of the applications discussed in this forum and probably only worth it if you have paying customers with valuable data.
For everyone else, the secured .env file, accessed by the systemd startup script is going to be good enough. Just make that file only root accessible and that Node-RED does not have elevated privileges.
