> Because non-natural keys are unnecessary in the presence of a natural key, and unnecessary things bring in complexity.
None of the things you've presented are actually "natural" keys, they are pieces of information that you've made assumptions about to shoehorn them into being usable as a "natural key".
> Use secure channels…
No channel is perfectly secure. As channels become more secure, they become harder to use and add complexity. The more places you store customer data, the more risk you create. The attempt to force semantic data to serve as "natural key" has now added risk and complexity to your entire communication infrastructure.
I don’t believe you understand what a natural key is, but aside from that, I’m not the one advocating passing around IDs like that isn’t a security failing. If you wouldn’t put it in a URL then you shouldn’t be passing it around anyway.
Then use a time-limited token, you can assign it to a particular role or support engineer too. You could do fancy things like making it pronounceable… there are so many options that do not involve passing around keys (while fearing you might leak an email address, which is less worrying than the key, IMO).
Because non-natural keys are unnecessary in the presence of a natural key, and unnecessary things bring in complexity.
> "Customer ID ### is having an issue with such-and-such."
Then you need access to the customer's ID, but the devil here is in the detail you didn't add, the such-and-such.
> communicating about a customer in insecure channels
Use secure channels…