For example, you can effectively architect with microservices without actually creating more deployable artifacts. This is because each GenServer is already a microservice. You build it from the ground up reasoning through failure modes and coordination. Those are easier to separate out into its own deployable artifact when the time comes, if it ever does.
People hear about code hot reloainding (where you deploy new code without shutting down the production environment) and think that’s the killer feature of the BEAM vm. Code hot reloading is a narrow use—case of a more general capability — you can directly write or patch new code in a running system in a live environment through the REPL. That has been very useful for improving the system, to stop the bleeding or identifying bottlenecks and trying out fixes, even when deployed as ephemeral pods in Kubernetes.
A lot of it is unfamiliarity with the tool and unfamiliarity with the paradigm. And of course, you can do distributed systems with other tools that people tend to be more familiar with, so go with what you know. Erlang is adaptable, but was built for a Telcom setting with a lot more permanence than today's popular cloud model with nodes coming and going.
On the other hand, an awful lot of large scale chat systems start as ejabberd and adjust from there; sometimes rewritten in another language, sometimes rebuilt in company specific Erlang while the service is running, sometimes without muvh adjustment.