Rust can be massively concurrent without Actors and GenServers.
So while the Actor model / let it fail approach changed the way I think, at the end of the day I found the traditional paradigms to actually be faster and cleaner to the real world applications that made me money.
IMO, that's a misconception. They work at different levels and I wrote a more in-depth explanation here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...
Although I agree the sentiment plays a role on adoption, because many ask "why Elixir when I have k8s", while in practice, if you like k8s, you should enjoy Erlang/Elixir. They apply similar principles at different scales.
So I don't think we could have made a dent on k8s, but rather, we should have positioned ourselves earlier within k8s strengths. :)
For perf optimisations, you have Ports or NIFs (irc), where Ports are just knowingly volatile processes, and NIFs are FFIs, which is an almost universal feature across all languages.
But I suppose your experience is based on use case. And I would agree that commercial BEAM language experience is generally thin on the ground, if you're role is to build an engineering team (though I can't imagine Rust expertise being that much more abundant either).
One thing I would add, is Erlang/Elixir's emphasis on multi machine concurrency is somewhat at odds with the serverless future we're moving towards. But ignoring that (especially with vendor lock in issues), I often wonder why Elixir hadn't put a larger dent in the popularity of Kubernetes. Because BEAM's approach to managing multiple services across machines seems both much more powerful, and dev friendly.