An Erlang release is not a static binary. It certainly is (or starts off as) a self-contained directory you can just unzip onto a server—but for the kind of software I'm talking about (RabbitMQ, CouchDB, Riak, etc.) you don't tend to install these things this way. You expect to install them using your distro's package manager. And, until very recently, distros did horrible things to those packages to force them into the FreeDesktop FHS mold. (And it still doesn't entirely work; the Erlang concept of priv dirs, for example, just doesn't map well onto even a reasonably-similar directory like /var/lib.)
That's what I mean by "deployability": the hell that is trying to convert your Erlang release into a distro package so that users can simply "apt-get install" it and have the distro maintain it for you; and so other software packages can declare package-level dependencies on it.
The reason that true static binaries ala Go would be better, is simply that it would stop the distro maintainers from messing with everything to quite the same degree. In such a setup, there wouldn't be a "system Erlang runtime", because Erlang would just be a baked-in part of /usr/bin/riak or /usr/bin/ejabberd. (Which wouldn't stop distros from making Erlang SDK packages for things like an Elixir package to depend on, but they wouldn't be involved at all in the dependency tree of the Erlang-release-derived packages on the system.)
Well there is something to do that. Exrm has some plugin to output a .deb. And it could be done for other package format. Once again, it is a tooling problem.
The kind of .deb produced by Exrm (or by just packing up the release using FPM or the like) would never be accepted upstream by a distro maintainer. This is a political problem, in that distro vendors have strong philosophical stances on how to do packaging, and those stances make packaging Erlang programs to suit their tastes really hard (and frequently impossible for newer software, since they say things like "you must depend on the system erlang package rather than embedding ERTS; and the erlang package on LTS will be held at R16, so it doesn't support maps.")
Of course, when people install your software "manually", you can distribute it however you like—a zip of an Erlang release, like a Java JAR, is already quite a convenient format for such installations all on its own. But when people want to install something that depends on your software (like, say, OpenStack depends on RabbitMQ), they don't want to spend nearly as much time thinking about your package. They don't know you exist, and they don't want to know you exist—they want the distro to handle that detail for them. So you're stuck fighting the distro. (And things like OpenStack are stuck doing non-distro-packaged releases to avoid the problem.)
Which brings me back to my original point: "snaps" are promising not because they sandbox packages, but because they're a countervailing philosophical movement on how software should be packaged. A distro that supports snaps is a distro that has made room in its heart for packages that don't want to break things down into little FHS-arranged dep-graph-divided bits. It gives them an out, a place to put these packages rather than just denying them outright.
That's what I mean by "deployability": the hell that is trying to convert your Erlang release into a distro package so that users can simply "apt-get install" it and have the distro maintain it for you; and so other software packages can declare package-level dependencies on it.
The reason that true static binaries ala Go would be better, is simply that it would stop the distro maintainers from messing with everything to quite the same degree. In such a setup, there wouldn't be a "system Erlang runtime", because Erlang would just be a baked-in part of /usr/bin/riak or /usr/bin/ejabberd. (Which wouldn't stop distros from making Erlang SDK packages for things like an Elixir package to depend on, but they wouldn't be involved at all in the dependency tree of the Erlang-release-derived packages on the system.)