Isn't this just shifting partly your trust from Slack to Amazon?
AWS Encryption SDK[1] is a well designed, battle tested data encryption library. Amazon KMS is a well audited service used by AWS to manage all sorts of keys and even supports external HSM integration.
For slack to build all this from the ground up would be time consuming. Hard part being 3rd party validation, penetration testing and certification.
[1]: https://docs.aws.amazon.com/encryption-sdk/latest/developer-...
However, this pattern is good and IMHO should be adopted by SaaS orgs that want to appeal to enterprise/regulated customers. We have a few vendors that we're sort of pressing in this direction, and a few have come to us with similar architectural proposals to address GDPR.
Specific to AWS it would be even better of the service allowed for the customer to host the CMK in their own account so they can choose to import key material if they like. This has some downstream implications on what you can do with the key vs. Amazon-generated CMK which may be advantages in some cases.
Looks like it does, based on https://aws.amazon.com/blogs/apn/control-access-to-your-data...
"With Slack EKM, you can use KMS in your own AWS account to create a Customer Master Key (CMK) that always stays under your control. Then, using key policies, you grant Slack access to use your CMK to generate and decrypt data keys."
Hard part?? That's just the laborious part. The hard part is in building an actually secure service.
A made-up example: assuming Brexit occurs, EU customers of a London-based SaaS chat service may no longer wish to keep that data outside of the EU. The easiest way to wipe it out quickly? Pull the key. Or perhaps your government is trying to compel you to produce data that you believe they have no right to. Some companies would rather have the option to destroy it and face the consequences, whatever they may be.