Your example has the downside of making the environment variables sticky, however, so it's not achieving the same thing.
source <(cat .env | xargs)
export $(cat .env | xargs)
unset $(cat .env | cut -d= -f1)
The last one unsets the environment variables that were set by the first command, ensuring they are not persisted beyond the current shell session.
If you are worried about forgetting to execute it, there are a couple of ways to work around it, depending on your case.
env $(cat .env) my-cmd-wanting-dotenv
ETA: the main difference between `env` and `dotenv` seems to be that `env` gets its arguments from the command line, whereas `dotenv` gets its arguments from a file. I think that's a fair difference, but I might also think that perhaps `env` should expand its offering to include some kind of `-f filename` option so that it can focus on the notion of "a configurable sub-environment for a command" and we can avoid subtle distinctions.
(. .env; my-cmd)Another advantage of env is that you can type `man env` and learn something useful; sourcing and subshells via syntax is a little bit harder.
Finally, I think the major point of this branch of the discussion is to explicitly decorate a command with a special environment. Starting up a subshell isn't the same thing. It might have the same effect, but you can see that you're creating a subshell, running a builtin in the subshell, and then running a command in the subshell. It is something of a difference between declarative (dotenv/env) and imperative (sourcing in a subshell) approaches, and inherits all the pros and cons of the imperative approach.
If it works for you, I make no recommendation against it.