Earlier quoted context omitted.
Give me 12 (a dozen) reasons to break the encryption and security of your users that could be acceptable to a non brain dead engineer and exclude surveillance and government snooping?
You're missing the fact that if a middleman does the encryption or has access to the decryption key, then encryption is already broken. A service provider is the middleman in this case and encryption only serves the purpose of you making sure that communications are with this service provider and not with another middleman. " Breaking the encryption " is not accurate. They don't need to break anything as your data is…
While this is true, I don't think it was his point. His point, I believe, was that the software should protect the data, and the engineer should not install or create APIs that allow someone to circumvent the security and privacy of the user — for any reason. He was replying to someone saying that higher ups could lie about the reason or need for such an API; his reply was saying that even the lie should be so obviously privacy-breaking as to be unacceptable. (Hence, he asked for examples.)
That said: legitimate law enforcement requests, i.e., warrants, would be an acceptable reason to me to implement such an API. That said, it should be auditable, so that you can verify it isn't being abused.