> (although, that's not technically true since irccloud does all the things you just mentioned)
Yes but then you're not using IRC, you're using IRCCloud. Its features are independent from the backend that is used; they could switch to Matrix or XMPP or a proprietary protocol for that matter, and the features would still be there. You can't expect the one you talk to to have IRCCloud and tell them "just search in the conversation history, it's there" because the protocol doesn't allow it.
The GP's answer is correct, Slack does a lot of useful things by default. That's why people like installing Ubuntu or even Debian but don't want to take time to setup an Archlinux or a Gentoo anymore: it's fun, but if I just want to do something other than tuning my install I'm not going to consider those distributions.
Now, the question is, does that mean that LFS or any bare distribution "lost" to, say, Fedora ? No, because they are meant for different needs. I'd say it's the same for IRC: it's best suited for people who are not interested in the full history and want to talk to people in a synchronous manner, people for whom text is a more than good enough solution and aren't necessarily interested in binary exchanges, people who like pseudonymity, etc
The client -> relay protocol for weechat relay is not the same as the client -> ircccloud protocol for irccloud, and both of those are _not_ IRC
All those clutches exist to support the deficiencies of IRC, which only proves the initial point: IRC in its current form doesn't do enough, and that's why Slack, with all of those features out-of-the-box, "won".
If you replace IRC with SMTP the story is very different. IRC has a lot of protocol problems but the biggest one was honestly just not having an IMAP equivalent. IRCCloud is just providing the complementary protocol to IRC. Its existence doesn't necessarily mean that IRC is a bad transport protocol.
IRC has no message storage - so not only it has no IMAP, it has no POP3 either.
And IRC is a horrible transport protocol because it handles errors by dropping messages. SMTP has both message-ids and explicit confirmation response to make sure that as long as server comes up, eventually, the message will be delivered exactly once. IRC does not; so it is simply not appropriate for the cases where each message matters.
What I was eluding to was that irc (as a server to server protocol) is fine. As a client it has deficits but those are quite literally smoothed over by websocket capable bouncers and weechat relay.
IRC The protocol is not competing with slack. The IRC ecosystem is. And yes, it lost.
You might actually be right, server-to-server IRC is good for finding an efficient path between all the servers in the network (ie it considers the network as a whole, not just a series of 1-to-1 connections) and send the minimum information required, so we should be able to keep that and make the client-to-server protocol different.
In short, make the relay/bouncer part of the server itself, and tell clients to connect with the relay protocol, not the IRC protocol. If there were some common standard for this second part that would actually be a great thing.
But we're talking about reasons people ended up choosing slack over something like IRC (or, really, any open protocol instant messaging specification).
The grand-parent comment raises good points, people want these things, being connected and reachable while not being connected to the server with any client and having a context later on. These are problems that can be solved but nobody has put effort into making a sexy product to do it. (and monetising that kind of product might be troublesome)
(although, that's not technically true since irccloud does all the things you just mentioned)