From my limited perspective: Keywhiz is a system to take secrets, stored in a database, decrypt them with an HSM backed key, and expose them as files on a server. Because the secrets are exposed as a fuse filesystem, they require zero special code in your applications. Most other secrets stores just provide you with an API that requires custom integration work. You could probably even modify keywhiz-fs to talk to a Vault server.
On the other hand, Keywhiz doesn't know anything about the secrets inside it, so there's not much out of the box for secrets revocation, and other operations like that. There's also minimal secrets generation: We just provide an API to handle that. The biggest sources of secrets for us are service-to-service TLS certs, generated from our deploy system, which just calls the automation API to put the certs it gets from our internal CA. Keywhiz has a plugin system for generating secrets, but it's quite simple compared to what Vault has.
Vault also has some operational decisions that seem scary to me. They have a scheme for "unsealing" a vault with a set of secrets an operator has to input. This seems quite likely to cause an outage, while defending against an attacker you've noticed but who hasn't managed to steal the secrets out of your unsealed vault. While operating, your vault is unsealed, so an attacker who gets root has your secrets in both Keywhiz and Vault, but a service restart causes an outage. If you could somehow (via physical access, perhaps) boot a malicious OS onto a Keywhiz server, and your HSM doesn't defend against that, you could read secrets. For Vault, you also need to steal the keys to unseal. But those are accessible to humans, so that's probably easy.
As for lifetime, we don't expect Keywhiz to go anywhere. It's a crucial part of running Square. We've been using it for years now (though only open-sourced it earlier this year), and will probably continue to exist as long as the company does.
I'm happy to answer any other questions, too.
