The only plausible way this can make sense to me is if he said "Running your own key service is a pain, use Amazon KMS". But that's a simple service question, probably wouldn't have taken up as much space.
You don't need 3rd party code hosting on Github, just use Gitlab or JIRA. You don't need some external CI service, run your own Jenkins node. Chat and email should also be internal (we use XMPP, a local Mattermost instance would be an alternative) and SSL-only.
You can do all of this with basically 1 docker command per install on your own dedicated hardware with a fairly underpowered machine.
And this prevents leaking of all sorts of information, not just production database passwords. If you don't trust your engineers, you have bigger problems, as another poster pointed out, if they can modify your software to simply report the password back to them, or just login to production and decrypt it, you're dead in the water.
External service SLA can be joke. It's always aftermath thought. Damage control is always on the customer side because customer has to rotate / invalidate leaked credentials, so first step for me is to have a process to invalidate credentials as often as possible.
I agree that using AWS KMS is the same architecture as using some other KMS that you run yourself, you just garner the benefit of their software and operational capacity and you buy service; this is the same as any other PaaS service at Amazon or some other vendor.
What's the value of Cryptex, though? Why not just store KMS-wrapped secrets in your config file and have Amazon unwrap them? Then you wouldn't be dependent on any local crypto implementation and you could use other KMS features, such as AEAD.