The flip side is that scaling the problem requires central relay points or lookups when the natural ability to cluster isn't there.
That becomes an even more difficult problem with deployments that in any other environment would disconnect and reconnect everyone from the nodes in the middle of active conversations.
Elixir/Erlang give you the ability to solve both of those problems in this domain. No central relay point and hot upgrades to live servers without any disruption to the millions of existing connections, in progress messages or in route audio conversations.
Doing all that while being able to dedicate a process to each one of those millions of users that both maintains their state between messages and handles monitoring their connection on reconnect attempts is also non-trivial. This is possible with Elixir and Erlang because those processes cost 0.5kb of RAM and the BEAM ensures responsiveness to all of them in the face of a piece of heavier/runaway code that would otherwise monopolize resources on the machine.
Go is the next closest option at 2kb / RAM per goroutine but Go also doesn't provide any type of ID mechanism for those routines so the closest equivalent that you'd get to be able to send a message from one to the other would be creating a channel for each routine to listen on.
Beyond code, OS level threads start at about 1mb, so the entire architecture has to change in order to even attempt to accomplish the same thing.