Slack is not the tool you'd want to use for anything but the most innocent work-related messages.

For that it is kind of usable, not good but one of the better that will get approved by management.

Again, I don't know the internals. But generally, an entity that has keys can forge messages. There's an incremental difference between the ability to snoop and the ability to forge. There's docs on the slack API, but none for the protocol, and not much is said about the new functionality.

It's certainly possible that was already there via other means, but a change in key control seems significant enough to warrant a UI indicator to me.

It depends on how it's structured, and with the most natural structure, this wouldn't be true. You'd be able to forge a message with the keys to exactly the same degree that you can forge a message coming from your coworker in Slack right now; short of social engineering to steal their password, anything else that would allow you to do that right now would be a major security vulnerability in Slack. And, more to my point, one that could be fixed.

Private keys here would be adding a layer of protection and making it harder, not easier, to forge anything.

Of course, an employer today could also claim to have evidence that you sent X to person Y, but Slack's own records would show that you didn't.

They'd have to go out of their way to make it so that merely holding the encryption key would allow you to fully forge messages.

Generally speaking, this is not adding power to the system, it's actually removing it. The reason why enterprise customers want this feature is not to give the customer more power, it's to remove power from Slack, because without this feature, Slack (not your employer) could forge messages. Assuming they implement this key stuff securely, this would remove the power to forge messages from Slack, and your employer would continue to not have it.