I'm not sure I agree. Runtimes like Erlang's work great for many things.
You just have to be aware that actors aren't going to magically get you more CPU cores — i.e. you can have as many IO-bound actors as you want; but a CPU-bound actor (done correctly, such that "gets out of the way" of actor scheduling) is just a regular CPU-bound preemptive OS thread; and you can only realistically have as many of those as you have CPU cores in your machine, before you start experiencing highly degraded performance.
Most systems don't need more than 100 (different) CPU-saturating things to happen at a time. If you do, actors won't save you... but nothing else will, either. You'll need to scale horizontally. (At which point, the actor model becomes very useful from another perspective — that of transparent distribution of messages between nodes.)
But tbh, there's a reason that, even on the systems Erlang was originally designed for and is "idiomatic" for — those being telecom packet switches — the Erlang software only performed the role of the control plane. There was also a data plane in each of those boxes — some kind of FPGA or ASIC — designed specifically for the job of applying a list of active routing rules at each input port, such that packets on that port would be unwrapped, maybe filtered, route-matched to an output port, maybe buffered to combine with other packets, then re-wrapped and emitted at said output port. The job of the Erlang code was to listen for signals bubbled up from the data plane, in order to build complex state-machines, do accounting, etc., resulting in change commands being pushed back down into the data plane ruleset.
Actors are great for keeping a bit of local state in order to make decisions, and coordinating with other actors and their local state to make more complex decisions.
Actors implemented naively — where all actors are uniformly green threads — are not so great for doing the same thing over and over, at scale. Telling N actors to do the same thing is no substitute for a DSP, nor for a tensor core.
But this isn't an indictment of the actor model, nor of current hardware, but rather of the current state-of-the-art in actor-model languages. You could totally create an actor-model programming language where actor-pools that are doing SIMD are transparently "promoted" during compilation into GPU shaders / FPGA gate-networks / etc. Nobody's done it, but there's nothing stopping anyone. (Anyone interested in trying this could probably do a proof-of-concept on top of Elixir's Nx library.)