The ability to solve a problem in a particular programming language is often dependent on the ability to express the problem in the constructs provided by the language. A very good example is the problem of concurrency. Doing something concurrently in a primarily procedural/OOP language often seems hacky and it is something that does not feel natural. The actor model that erlang implements is a very powerful model for certain class of problems and concurrency is one of them. Erlang the language, minus the OTP, is extremely small and once you get over the culture shock experienced when it comes to syntax, things will seem pretty easy. OTP isn't magic. Its years and years of erlang experience packaged into one neat library, solving commons problems, so that you can concentrate on your work instead of reinventing the wheel.
Reading Joe Armstrong thesis 'Making reliable distributed systems in the presence of software errors'[1] is highly recommended if you want to understand why things are the way they are.
[1] : http://www.erlang.org/download/armstrong_thesis_2003.pdf