Developers came up with .env because they would run apps on their own machine and wanted to pass variables to their application without having to set them in a command-line or environment-variable every single time they ran their app. And it works great for that. If you're one developer, running something locally, sure, just read some lines from a file. And if you're a team of developers, and most of you have the same lines you want to use, but maybe just a few of them you want to change per developer machine, fine, either keep .env out of Git, or keep a .env.local for the non-Git stuff. Again, simple, works fine.
Then you want to run your apps in production, with different lines. And then you want to run it on a test/stage/qa machine too - again, different lines. And maybe you hard-code those into separate files (.env.prod, .env.staging, .env.test) and load them depending on which of the 2 or 3 machines you have running your app. Again, simple, works fine.
Until the problems start.
Secrets in the .env? Now those are in the code, which gets cloned everywhere, and can be stolen. "Encrypted" secrets in .env? Now you have to manage a secret key out of the file, in addition to the encrypted secret in the file. Everyone has access to the secret? Now people can use those secrets, or access different machines, potentially creating problems or exceeding their authority, and there is no way to know who did what because it's one shared secret. Somebody leaves the company? Now you need to rotate the secret (which nobody does).
Ephemeral containers/deployments? Now the .env entries don't match the new hostname. Want to support multiple hosts? One hostname in the .env line doesn't work anymore. Want to scale horizontally? Now your "prod/test/dev" files are more of an environment type than a specific host. Your RDS database's hostname, or an old IP address, has changed? App is broken, time to update all the .env lines referring to it and re-deploy the app.
These are all problems that you might or might not run into. But they are problems that do exist in the world; we know they happen, and we know how to avoid them. You decide whether you're going to wait for them to bite you, or avoid them altogether from the very start. If you do the former, you're acting like a Systems Engineer, designing a system to be resistant to known failures. If you do the latter, you're not.
You may not want to do extra work you feel is unnecessary just to avoid a possible problem. But other professions do this anyway, by regulation, because (for example) as a society we we don't want to allow houses to burn down from a preventable problem. Example: If you run wire in a conduit, the conduit must be a minimum size depending on the number and type of wires you run in that conduit. You may think it's annoying that you have plenty of space left in your conduit; why should I have to change my wire size or conduit size? But if the wires take too much current, and don't have enough airflow/space between them, they can heat up and start a fire, or a short, which could cause a larger problem somewhere else (like taking out a hospital's ventilators, as one example). Doing the extra "unnecessary" work prevents fires. That's why Systems Engineers don't use .env files. Their job is to build reliable systems, not just roll out a feature and cross their fingers.