When security engineers and cryptographers analyze an application, they frame their analysis in the context of security goals, threat models and categories of risk. They don't begin from the perspective that application security is a boolean property - i.e. that the software is either secure under the most strenuous of requirements or simply insecure. That's not how any of this works. All security analysis exists on a continuum between safety and usability.
Not all messaging software needs to be secure enough that it could be used as an anti-censorship platform or to facilitate secure communication from journalists in totalitarian regimes. For most companies it's enough that their data is protected through strong application security mechanisms, and Slack devotes significant resources to that task.
In addition, customers choose to use Slack for its features. As others have pointed out, some of these features (like message search, or an audit log for direct messages between team members) cannot exist under an end-to-end encrypted model. If you want to use Slack, that means you want to use Slack's features. It's pointless to demand Slack to become something it's fundamentally incompatible with. If you want confidentiality assurance at the highest echelons of computational security, just use something else.