That's not what I'm saying, what you mention can be done indeed.
What I say is that if you are in a machine with an already running docker container, one you don't have the corresponding `run` command of (i.e. you _can't docker run_ for whatever reason), changing the environment variables of that container is tricky.
You could always run the `env` command inside of the container to get all of the set environment variables. Then you can define, reconstruct and run your container with whatever args you want.
But yeah the env_file approach is the way to go here. I've been using Docker in production since 2015 and never ran into your use case. I always had an .env file ready to go that was loaded in with env_file and always had control over being able to run the container with whatever command I see fit.
And in cases where I have no control over how things are run (like Heroku), environment variables still work because a ton of hosting platforms expect you to set and read them for various configuration.
And you can also commit an example env file to git with no secrets so developers can `cp .env.example .env` to get going in 1 second.
The environment variable pattern is incredibly standard in the world of web dev.
Also if you specifically want to modify a file and re-run the container look at --env-file arg to docker run.