You shouldn't, you should use Erlang's model of having a single process ultimately manage the state make implementing transactions easy. Several processes can concurrently try to reserve seats, but ultimately they all have to get in line and submit their reservations, receiving either e.g. {ok, NewState} or {conflict, NewState}.
That's the limitation of Erlang, right there. They get in line, creating a bottleneck. You could have 10,000 Erlang processes, but they all wait in line for this one process to service them.
If you use transactional memory with threads and mutable state, then all your booking processes can access the board state in parallel with ACI properties. Obviously, parallelism is still limited, as it always it, but as long as your booking processes are accessing different parts of the seat data structure, they can run in parallel. If they try to access the same part of the structure at the same time, all but one will be rolled back, but that one still gets through. Hopefully, they access different parts of the structure and sail through.
Your suggested Erlang program has no parallelism in it at all (for the isolated part of the seat booking of course), and will not scale to 2 cores, let alone the 64 cores I have in my machines at work.
Erlang is not about parallelism, it's about fault tolerance. It's about "making reliable distributed systems in the presence of software errors" (as Armstrong's thesis is titled).
How will your STM example behave if the computer managing the transactions suddenly has a massive hardware failure?
I completely agree with you about fault-tolerance. However Erlang, CSP, actors and message passing are heralded as the key to parallelism. The Erlang book still promises n-times speedup for n-cores, with not enough of a caveat.
I'm not familiar with the plane scheduling problem, there is probably room to parallelize it further. I suspect people are far less likely to book seats on both sides of the aisle(s) at the same time, for example. Knowing more about those things, airline regulations, and so on will probably present other opportunities.
You could do as jlouis suggested and have each plane or flight manage its own seats/places. The state of different flights or planes isn't necessarily related and can be handled differently, giving you a smaller isolated unit than "everything at once".
This gives place to parallelism as soon as you have more than one plane to contend resources for in your concurrent model, which is most likely the case in the real world.
If you have only one plane, then you likely won't need to scale.
