Don't keep encrypted secrets in your git repositories, if for no other reason than that it makes access revocation deceptively difficult --- but also because it encourages you to have a development team in which ordinary devs have a full complement of secrets on their laptops at all times.
Instead, keep secrets "out of band" and supply them to applications as part of your deployment process.
I definitely agree that tools like vault or keywhiz (or automated permission management using AWS roles) are the right way to do things. As as an added plus, a well-designed system can be configured to issue temporary credentials, where every AWS secret and SSH key automatically stops working within 24 hours. And you can log every secret request, and you can set explicit policies about who can access which secrets. Once you see this stuff working, it's hard to imagine ever going back.
But unless you're working at a very large scale, you probably still have an offline secret database somewhere, just in case you need to wipe and rebuild your secret management system. Or at the very least, you may need to keep copies of the individual key fragments needed to unlock your vault server's secret database when booting a new vault replica.
And at this point, encrypted secrets can still play an important role, especially if access is limited to a tiny number of people. Of course, if one of those people leaves the company, then you need to roll every single secret in your organization. (Which is actually an interesting exercise to do every couple of years, anyway. I increasingly believe all secrets should have TTLs.)