One dimension I would add, since it usually decides it for regulated shops: governance and audit.
- UC-managed secrets (catalog.schema.secret) inherit UC's permission model and land in the same audit / system tables as everything else, so "who read this secret and when" is answerable in one place. Workspace-scoped secret ACLs are coarser and sit outside UC.
- Azure Key Vault-backed scopes are effectively all-or-nothing: anyone with READ on the scope can read every secret in the backing vault, and the scope authenticates as a single identity. If you need per-secret separation you end up creating many small vaults, which gets unwieldy fast.
- KV-backed does give you one real advantage: rotation happens in Key Vault and consumers pick up the new value with no change on the Databricks side. With native secrets you have to push the new version yourself.
- At high job concurrency, watch KV throttling (429s). A few thousand concurrent tasks each fetching a secret at startup can hit the vault's rate limits; native secrets do not have that failure mode.
Where we landed: native UC secrets for things the data platform team creates and rotates itself (service tokens, connection strings), KV-backed for anything owned centrally by security that already had a rotation process. Agree it is not one OR the other.