Uma das vantagens dos modelos de processamento de mensagens, como atores e agentes, é que os problemas tradicionais de simultaneidade (principalmente a sincronização do estado compartilhado) não são mais um problema. O ator pode manter o estado privado e atualizá-lo livremente, sem bloqueios. A estrutura do ator garante que apenas uma mensagem seja processada por vez. Com o processamento serializado, o código pode ser gravado de maneira livre de bloqueios.
No seu exemplo de usuários salvando um formulário, assumindo que o ator mantinha uma Lista de alguns dados de cada formulário, o ator pode atualizar a lista sem bloqueios, porque a estrutura garante que apenas um formulário será processado por vez. Tradicionalmente, você teria que bloquear os acessos à lista ou usar uma lista simultânea.
A estratégia de concorrência é um assunto um pouco diferente e ainda é de sua responsabilidade (sem que a estratégia seja a estratégia mais comum). Para mudar um pouco o seu exemplo, digamos que os dois usuários tentem atualizar a instância do mesmo formulário ao mesmo tempo. Sem estratégia de concorrência, as alterações de uma pessoa substituem a outra (provavelmente a última vence). Tudo bem, mas, na melhor das hipóteses, isso resulta em comportamento inesperado para o usuário cujas alterações foram substituídas. Se eles visualizarem o formulário que acabaram de alterar, haverá valores inesperados (do outro usuário). Na pior das hipóteses (quando não estamos falando apenas de atualizações de formulários, mas de pedidos de remessa), isso pode resultar em perdas de vários tipos (tempo, receita etc.).
O uso de uma estratégia de simultaneidade ajuda a identificar esses casos e a resolvê-los com base nas regras de negócios. Por exemplo, a Concorrência Otimista faz com que o usuário envie a versão do formulário que está atualizando. Quando o ator processa a alteração, percebe que o segundo usuário pensa que está atualizando a Versão 5 quando o formulário está realmente na Versão 6 por causa da atualização do primeiro usuário. Agora, pelo menos, podemos notificar o segundo usuário que o formulário já foi alterado desde que ele começou a editá-lo. Ou quaisquer regras que a empresa queira impor lá.
No caso de atualizar um formulário, você provavelmente não liga muito para simultaneidade (depende, eu acho). Mas em outros casos, pode ser uma coisa muito importante, pelo menos, poder verificar e lidar com violações. Você pode até querer ignorar a violação de concorrência, como se os usuários alterassem seções diferentes (para continuar a analogia do formulário). Ou se a alteração tiver um grande impacto nos negócios (uma grande encomenda), você deseja aceitá-la e resolver pequenos conflitos mais tarde (por exemplo, a atualização anual das informações de contato não foi concluída).
Acredito que a Akka tenha várias outras dimensões, como a maneira como lida com falhas, supervisores etc., que são considerações importantes para os devops.