Because it turns out to be a colossally chatty and stateful protocol in an era of stateless mobile devices. Plus it's not HTTP... the rule at the network layer these days is basically "80 and 443 are open; every other port is good-luck-to-you."
OP's assertions it was more reliable are assuming a very static network. Modern protocols (Slack included) are far, far more reliable on a highly-unreliable transport layer.
Not true. Or rather: in theory what you are saying would be true, however in case of Slack it simply doesn't work: Slack handles unreliable transport worse than IRC - IRC never dropped or duplicated messages; you could reconnect to IRC client under a tmux session from anywhere and it would do the right thing.
> you could reconnect to IRC client under a tmux session from anywhere
That would actually be a pretty decent solution if it could be automated on a mobile device: run the IRC client in the cloud and then have tmux auto-reestablish every time it gets its connection dropped while the mobile device moves around.
I'd have to see it in action to be confident that a continuously-dropping-and-reestablishing tmux won't drop incoming messages or double-send though.
