Even this article, which recommends keeping your secrets in environment variables, tells you to implement that by storing them in the filesystem. The advice isn't to avoid storing your secrets in the filesystem; it's to avoid storing them in version control.
It is apparently an exercise for the reader to figure out why it's better to read your secrets out of the environment, which read them from a file you provided, than to read them from your own file yourself.
Linux already stores plenty of secrets in files in /etc. Just do the same: the root protected init file for your app likely has a mechanism for passing an env var to the new process. Systemd and supervisor do. Then pop os.environ instead of reading it, and you are safe from bots and script kiddies, which is likely your threat model
This has the same problem that OP refers to with regards to DEBUG: It remains in the environ, and for example if you forgot to set DEBUG=False, Django will just dump the whole environ on the error page.
If you can call bitwarden from within the python code somehow, such as with subprocess, that would be better.
This is only a solution for inputting the password. Generally you would set it as a variable on the server (eg: heroku sets this) - but you could provide it on startup for local development/testing.
You need to unlock bitwarden. As mentioned above - this is more a solution for local development (against a non-local db).
For a service, one would need some kind of secret management - but a shell script could set this variable/value for input to eg docker or a k8s setup. Or the service (eg: heroku) could handle it.
"What happens on reboot" is a good question for a scheme that involves not using the filesystem, but bitwarden is not such a scheme. Everything will be fine after a reboot.
You need your app to have the bitwarden decryption passphrase to read it. Do you intent to enter that manually if the server reboots ?
If not, then it's a secret you must manage, and you are back to square one: either using a simpler solution, use a hardware key, or going full secure vault service, with privileged first request, and so on.
How would you avoid that?
Even this article, which recommends keeping your secrets in environment variables, tells you to implement that by storing them in the filesystem. The advice isn't to avoid storing your secrets in the filesystem; it's to avoid storing them in version control.
It is apparently an exercise for the reader to figure out why it's better to read your secrets out of the environment, which read them from a file you provided, than to read them from your own file yourself.