I am currently in the process of learning Erlang, and here are my impressions.

In the paper A Note on Distributed Computing, Waldo et al argue that having a distributed object system is bound to fail no matter how hard one tries.

  Differences in latency, memory access, partial failure, and
  concurrency make merging of the computational models
  of local and distributed computing both unwise to attempt
  and unable to succeed.
  ...
  A better approach is to accept that there are irreconcilable
  differences between local and distributed computing, and
  to be conscious of those differences at all stages of the
  design and implementation of distributed applications.
  Rather than trying to merge local and remote objects, engineers
  need to be constantly reminded of the differences
  between the two, and know when it is appropriate to use
  each kind of object.
  

Erlang works around this problem by making the local object model identical to the remote one in all aspects except latency. The semantic model is copy-on-send asynchronous message-passing. This is inconvenient when working with local components, as you rightly point out. But putting up with this inconvenience up-front makes it easier to refactor towards a distributed system later much easier. The language attempts to work around the inconvenience of asynchronous message-passing using functional abstractions - which is largely what OTP seem to be.

BTW, the language can be used in a synchronous context. It works just like another functional language with all code executing from start-to-finish on a single thread of execution.

[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7...