Firstly, if an actor crashes and restarts, you only lose the current message that was being processed, and not the entire mailbox.
A limited mailbox has a limit on the number of messages that it can queue before it starts blocking the sender and will not allow the item if the queue does not drop while the sender tries to enable the item. If you have memory problems and can handle the potential loss of a message, you might want something similar. An unlimited mailbox has no capacity limitations, so there may be a memory problem if it is flooded.
Whether it is limited or not will affect whether it blocks or not. The lock is usually small for performance, and should be avoided if the situation does not require a limited mailbox. Therefore, the default mailbox is not limited; this will give much better performance than a limited counterpart.
A single-user unlimited mailbox is likely to be the fastest, as it is optimized only so that one consumer ever removes things from the queue. This means that you cannot use a dispatcher that allows an actor instance to steal items from another instance of the instance instance (duplication / theft of work), but if you do not care, then this mailbox may be the best choice for performance.
Priority-based mailboxes allow you to provide code that allows you to queue up depending on some attributes of the messages themselves. This allows you to prioritize messages yourself, and then they will move items with higher priority to the front of the queue, regardless of the usual FIFO rules.