This is a bad analysis. Sure, Vault is infrastructure you have to maintain. For a small team, it's probably not a good tradeoff. But even if you dismiss Vault's

This is a bad analysis. Sure, Vault is infrastructure you have to maintain. For a small team, it's probably not a good tradeoff. But even if you dismiss Vault's ability to do dynamic secrets (which is actually one of its primary benefits), the security model for Vault is much stronger than KMS-encrypted secrets in Git. The author appears to be claiming that protecting your Vault server from a local root privilege escalation attack is so difficult that it's better to ... instead rely on the security of your team members' IAM credentials which are floating around on their workstations, and which talk to KMS over a public API. No matter how you manage your secrets, one of the most important factors is how often you rotate your secrets. If you can't transition to fully dynamic just-in-time secret provisioning that Vault can provide for certain backends (including AD, OpenLDAP, PKI certs, various database engines, Consul, and more), then you still ought to be rotating your secrets on a regular basis. And in that case, a tool like Vault (or AWS Secrets Manager or GCP Secret Manager) is going to be a lot easier to build a rotation framework on top of than a git repo with secrets encrypted in place.