Actor model vs sharing Arc<Mutex>, why use one over the other?

Hello, I've lately written benchmark of simple Actor model implementation and using Arc<Mutex>. Unsurprisingly Arc<Mutex> was faster way to share state (2-3 times faster depending if I would return back result using oneshot channel), but this got me thinking. What really are the advantages of Actor model in language like rust?
In my mind the biggest thing I see is that there's common structure to long-running process. I get it that keeping state in one thread listening on messages allows us to avoid mutex, but why would we if it's not more efficient? I can also write methods accessing this mutex so the person that holds reference to my struct doesn't even need to think about this mutex.
I feel like there must be something that I'm missing here considering the fact that this pattern is liked by so many, but the only thing I see is that having standarized way to build program allows you to have distributed pools of nodes running some tasks (I think that ractor crate is going to have this feature), but I don't see the benefits in a single app. Is it really just a convention, not really better or worse because of it's benefits but still useful because any convention is better than lack of common structure?
I've looked for compelling answer that would 'click' in my head, but sadly could not find anything. I'm asking because I'm writing program that seems to fit what actor is supposed to do well, but my current implementation that shares Arcs and Mutexes doesn't seem to be limiting me in any way.

I guess my question would be - how would you decide when to go for Actor model? Why do you think it's better approach instead of keeping references to your struct? Thanks for answers :-)