There is one massive thing that I picked up from using Erlang that you failed to mention and I think should be pointed out. I have applied it in various ways outside of Erlang with a large amount of success (and the habit has caused no end to frustrations when dealing with external libraries, particularly on the JVM). If there is an error of some sort, but it can be recovered from, is a potentially anticipated scenario, etc. and can be handled at the point of occurrence, handle it. If it can't be handled, return a response indicating an error. If it is an exceptional condition, blow up and let the next level higher deal with it if it can, and so on. You can enumerate any number of ways that something can fail, but you will never catch all of them. However, exceptions are not an error communication device, they represent a condition that cannot be handled where they occurred.

It didn't really sink in fully for me until I had to write my first full non-trivial Erlang application from start to finish. However, once it clicked, every piece of code I wrote was significantly more predictable, easy to reason about and had significantly less bugs.