BEAM is pretty deeply untyped due to its fundamentally untyped [1] communication protocol. There's some logical reasoning behind this choice, which is that by not having a typed communication protocol, it can defer handling mismatched types to the application layer. Since it is deeply designed with the knowledge that it will be used in a clustered context and that it is inevitable that there will be version mismatches within a cluster (during upgrade if nothing else since simultaneous anything is impossible within a cluster, including upgrades), this is a somewhat reasonable compromise approach to the problem. If you do add typing on top of BEAM you still need some sort of solution to this problem with will probably have some sort "unsafe" equivalent.
[1]: In the sense you mean here, anyhow. It has a selection of atomic types, int, list, tuple, etc., but there's no "user" types as one would have a strong typing system for. It's not an exact match but if you imagined a programming language that had nothing but JSON, not Javascript, Javascript has user types, literally just JSON as your underlying data model, you get pretty close to BEAM/Erlang.
[1]: In the sense you mean here, anyhow. It has a selection of atomic types, int, list, tuple, etc., but there's no "user" types as one would have a strong typing system for. It's not an exact match but if you imagined a programming language that had nothing but JSON, not Javascript, Javascript has user types, literally just JSON as your underlying data model, you get pretty close to BEAM/Erlang.