How to structure wrangler.toml for env, staging, & production?

I’m wondering how best to structure my wrangler.toml to support dev, staging, and production.

One option is shown below. Where the default is to assume dev settings and then override these settings in staging and production environments.

An alternative could be to add a [env.dev] section, as I see this used in the docs. But why? Is one approach considered best practice or is it just personal choice?

Can anyone comment or point to a repository of example wrangler.toml files I could refer to or can you tell me which approach you use.

Thanks.

# wranger.toml
name = "my-app"
main = "src/index.ts"

vars                      = { ENVIRONMENT = "dev" }
route                     = { pattern = "dev.example.com/*", zone_id = "<zone_id>" }
kv_namespaces             = [{ binding = "MY_KV", id = "<kv_namespace_id_dev>" }]

[env.staging]
vars                      = { ENVIRONMENT = "staging" }
route                     = { pattern = "staging.example.com/*", zone_id = "<zone_id>" }
kv_namespaces             = [{ binding = "MY_KV", id = "<kv_namespace_id_staging>" }]

[env.production]
vars                      = { ENVIRONMENT = "production" }
route                     = { pattern = "app.example.com/*", zone_id = "<zone_id>" }
kv_namespaces             = [{ binding = "MY_KV", id = "<kv_namespace_id_production>" }]

I wrote up what I’m doing here: https://justin.poehnelt.com/posts/cloudflare-workers-wrangler-dev-staging-prod/

I wish there was a better way to promote automatically based upon error rates.