I never used Erlang, and I'm a functional programming fan. But languages based on heavy VM that abstract OS away always make me doubt that's the right direction.
That's not a crazy instinct, and maybe if OSs were better you would even be right, but there's not really another way to get a skrillion communicating processes that can all crash/fail independently. Without a dedicated VM, all the other approaches are either less safe or too inefficient.
I consider BEAM an indication of a direction that OSs could and maybe should move. It's even possible to run BEAM on bare metal, (almost?) entirely in place of the normal OS.
I've built a hobby OS around BEAM... BEAM doesn't require a whole lot from the OS, I built a minimal kernel that runs a single process, which you could consider a unikernel or at least very close. I had originally wanted BEAM in ring 0, but I had a lot of trouble getting started. This way, I can just use a pre-compiled BEAM for FreeBSD and don't have to fight with weird compilation options. Anyway, with x86-32 at least, I can give my Ring 3 process access to all the ioports and let it request a mmap of any address, so the only drivers I need in the kernel are IRQ controllers, timers, and pre-beam console. Once beam is up, console i/o and networking is managed from erlang code (with a couple nifs)
It's almost like an OS in itself and initially designed to be like a more capable and robust OS on top of rather constrained computers. In my experience it's trivial to shell or port out to the environment when I want to, and I also see people that I don't think of as highly skilled low-level programmers do things with NIF:s so that can't be exceptionally demanding either.
I consider BEAM an indication of a direction that OSs could and maybe should move. It's even possible to run BEAM on bare metal, (almost?) entirely in place of the normal OS.