Actors are better suited for highly heterogeneous task sets, where am actor or small set of them correspond to some task and you may have thousands or more.
Homogenous tasks should use an approach that is aware of and takes advantage of the homogeneity, e.g., the sort of specific optimizations a framework might make to orchestrate data flows to keep everything busy with parallel tasks.
You can use actors for orchestration, but you're really just using them because they're there, not because they bring any special advantages to the task. Any other solution that works is fine and there would never be a particular reason to switch to actors if you already had a working alternative.
The problem you face is not so much a lack of such things existing but such a staggering multiplicity that it is hard to poke through them all, and despite the sheer quantity, you may still find that your particular problem doesn't fit any of them terribly well. You can find anything from OpenMP, which amounts to "let's try to treat a whole bunch of resources a lot like one big computer" https://en.wikipedia.org/wiki/OpenMP, through things like Kubernetes which can be used to deploy all kinds of "worker nodes" for all sorts of tasks even if it doesn't do the orchestration of the task itself, and so many combinations of anything in between, plus you have all sorts of clustering technologies, message bus technologies, on-demand VMs spinning up, so many primitives that even if they aren't designed for this can be relatively easily put together into whatever it is you actually need that it is all rather about bewildering abundance than shortage.
There's also the entire category of "data lakes" and other nouns that have "data" applied as an adjective that includes various orchestration techniques because just being storage isn't enough, that is its own entire market segment.
