I use them in python_dotenv for declaring environments that I use to provision infrastructure, as an example:
Example, where we have:
env_type="dev"
env_name="myappenv"
primary_subnet_pod="${env_type}-${env_name}-gke-pod-subnet"
primary_subnet_service="${env_type}-${env_name}-gke-service-subnet"
Which I then might want to use further down, override with defaults, etc and so forth. It strikes a decent balance in that it's a bit more powerful than a static .env file, but doesn't require you to go full-on templating language with Jinja and the like. It's also cross-platform enough in that you could throw a .env in somewhere and expect most languages to have a client library to parse and load it into env.
If your use-case is right in that sweet spot it's a pretty good tool. But the behavior, as noted, isn't specced so I can't trust go_dotenv or rust_dotenv or whatever other library to treat it the same way.
Interestingly, in practice, it seems like the Node lib is the canonical version that inspired these other ones so in a way it serves as some sort of unofficial spec. It's not something I would write production grade code trusting the unofficial spec on though.