Yes, the fact that you can send email to people who aren't using your email system is the main thing that's keeping chat services stuck as part of a company's communication tools and not being the entire (or almost entire) thing.
I actually wrote the easy 50% of email back compatibility for a chat app once - it wasn't as hairy as I expected it was going to be. Everyone has a unique username (or at least username+org pair) so use that to generate an email address for them. Similarly, generate an email address for every group/room. When you receive an email for one of those addresses, use the from headers to find/create a new pseudo-user and dump the body of the email in as a chat message. When someone writes in chat that has a pseudo-user as one of the people watching that chat, send them an email with that text and throw in a few previous messages as a fake reply chain for context.
There are a lot of hairy details about thread management and making sure you don't send pseudo-users too many emails and dealing with all the messed up headers that different platforms send you and trying to only extract the actual message and not the signature/replies from an email and attachments so on that I only worked on a little before the whole thing was shuttered. But it was really cool. Email users tended not to notice that anything was different (they're used to email looking weird from various services) and chat users got to stay in chat that was a little awkward instead of having to switch to a different tool entirely to talk to people outside the organisation. (And, if all the different chat services started doing it, you'd get really janky chat federation for free!) And it lets you get a lot of stuff that gets made as Slack integrations for free, too. Why bother setting up a bot to post to chat when a Jenkins build fails when you can just give Jenkins your dev chat's email address and let it send emails?
I actually wrote the easy 50% of email back compatibility for a chat app once - it wasn't as hairy as I expected it was going to be. Everyone has a unique username (or at least username+org pair) so use that to generate an email address for them. Similarly, generate an email address for every group/room. When you receive an email for one of those addresses, use the from headers to find/create a new pseudo-user and dump the body of the email in as a chat message. When someone writes in chat that has a pseudo-user as one of the people watching that chat, send them an email with that text and throw in a few previous messages as a fake reply chain for context.
There are a lot of hairy details about thread management and making sure you don't send pseudo-users too many emails and dealing with all the messed up headers that different platforms send you and trying to only extract the actual message and not the signature/replies from an email and attachments so on that I only worked on a little before the whole thing was shuttered. But it was really cool. Email users tended not to notice that anything was different (they're used to email looking weird from various services) and chat users got to stay in chat that was a little awkward instead of having to switch to a different tool entirely to talk to people outside the organisation. (And, if all the different chat services started doing it, you'd get really janky chat federation for free!) And it lets you get a lot of stuff that gets made as Slack integrations for free, too. Why bother setting up a bot to post to chat when a Jenkins build fails when you can just give Jenkins your dev chat's email address and let it send emails?