So let's say I implement some job scheduling system like you suggested: One job actor instance per job and one scheduler actor instance to create new job actor

So let's say I implement some job scheduling system like you suggested: One job actor instance per job and one scheduler actor instance to create new job actor instances. The job can be in one of many lifecycle states like started, in progress, etc. Unfortunately, since this is a distributed system with faults there can be network partitions, crashes and such at any moment, so every time the job actor changes state it has to write it down in some highly available database so it can be restarted if it crashes and every time it wants to do anything it has to check that database to see if someone else is already doing it. At that point the actors are basically stateless, so what's the benefit of using actors in contrast to Futures or similar stream-processing frameworks, whose abstraction boundaries are not coupled directly to operational concurrancy concerns and thus much more maintainable when you have more complicated workflows with fan-out/fan-in stages? (Not to mention that Akka Streams provides this API on top of actors with the ability to distribute work across nodes in a network without users having to know anything about the actor model).