I don't think .env.example is the only way to document available environment variables... and for libraries or frameworks is almost absolutely the wrong way. That's what configuration documentation is for.
IMO, a framework shouldn't even load .env on its' own, it should rely on the upstream application to load its environment as appropriate. For that matter, depending on your orchestration, you might not use .env files at all, you may inject parameters from a secrets repo as part of k3s/k8s...
Now, you should document environment variables that are meant to be modified by users, but even that isn't always the case as outlined in the articles... sometimes they're for testing.
For something I've been working on the past month or so, I have specific tests that will only work in Windows and with native database install (not via Docker)... so there are environment variables to test those scenarios separately. These aren't meant to be used downstream at all.