One of the advantages of message-processing models like actors and agents is that the traditional concurrency problems (primarily synchronization of shared state) are no longer a problem. The actor can keep private state and update it freely without locks. The actor framework ensures that only one message is processed at a time. With serialized processing, code can be written in a lock-free way.
In your example of users saving a form, assuming the actor was keeping a List of some data from each form, the actor can update the list without locks, because the framework guarantees that only one form will be processed at a time. Traditionally, you would have to lock around the List accesses or use a concurrent list.
Concurrency strategy is a slightly different matter and is still your responsibility (with no strategy being the most common strategy). To change your example slightly, let's say that both users try to update the SAME form instance at the same time. With no concurrency strategy, one's changes will overwrite the other (probably last one wins). That's fine, but at best this results in unexpected behavior for the user whose changes got overwritten. If they view the form they just changed, it will have unexpected values (from the other user). At worst (when we're not just talking about form updates, but things like shipping orders) it could result in losses of various kinds (time, revenue, etc.).
Using a concurrency strategy helps to identify these cases and be able to resolve them based on business rules. For instance Optimistic Concurrency has the user send the version of the form it is updating. When the actor goes to process the change, it notices that the 2nd user thinks it's updating Version 5 when the form is actually at Version 6 because of the first user's update. Now at least we can notify the 2nd user that the form has already changed since they started editing it. Or whatever rules the business wants to enforce there.
In the case of updating a form, you probably don't care as much about concurrency (depends, I guess). But in other cases, it may be a very important thing to at least be able to check and handle violations. You may even want to ignore the concurrency violation, like if the users changed different sections (to continue the form analogy). Or if the change has a large impact on the business (a big order), you want to accept it and resolve minor conflicts later (e.g. yearly contact info update hasn't been completed).
I believe Akka has a number of other dimensions like how it handles failures, supervisors, etc. that are important considerations for devops.