Not that I'm advocating the approach but I think the benefit is that if your recipient is out of action then your callee survives
In a typical Simula I program (C++ Java PHP C# etc) if you fatal in your recipient's object your callee and the entire program is going to come crashing down, in something like erlang the callee can keep going
Essentially, it's good when you need it but an overhead when you don't, kind of like async in my mind, use it when you absolutely need it, but otherwise, you'd be better operating without it
As parent mentioned, there is overhead to using async: both in actual execution (e.g. likely spinning up another thread, plus creating a future object) and cognitively (in terms of following control flow, and knowing when exactly things are happening).
It's not that it isn't great when you do need it, but there are also plenty of cases where you don't need it and it's just unnecessary overhead.
In a typical Simula I program (C++ Java PHP C# etc) if you fatal in your recipient's object your callee and the entire program is going to come crashing down, in something like erlang the callee can keep going
Before jumping to putting everything on a queue, there are downsides like you've identified which is why there's this comment from Rich Hickey on the erlang variant of Clojure: https://github.com/clojerl/clojerl#but-but-rich-hickey-lists...
Essentially, it's good when you need it but an overhead when you don't, kind of like async in my mind, use it when you absolutely need it, but otherwise, you'd be better operating without it