It isn't for Erlang. If you look at the history of Erlang the language was released and after it had been in use for a while the language design team went around, identified the design patterns in use and implemented them as behaviours - the OTP system.
Where design patterns go wrong is in being a description of how to build a wheel (so you don't have to redsign the wheel) - what you really want is a wheel (so you don't have to rebuild the wheel).
This blog speaks from my heart: maybe I managed to wrap my head around OOD and even tried some AOP, but in the end, as I am - in the most general sense - a data miner, I always crave for high-throughput and low resource consumption. Every language I looked into was the same: do it OO, and it is nice, but do it functional and it processes loads of data at much better speeds. I settled for Python and C because the combine a huge library with sufficient functional paradigms (and, with "goto"-like-statements, you can even do coroutines in C!). Now we have multi-cores and everybody is starting to look into how to program for them, with functional patterns being the most efficient to adapt for that hardware. I at least have the strong feeling that what this guy is saying is quite true. (Although I am disappointed that Erlang wasn't on his list, as I just picked that as my next target language to learn... :)).
I'm working on a message passing style RPC using Couch replication and state machine documents, it encourages idempotent responses in the server's async processes, which is similar to functional operation.
RPC is a domain where functional patterns really shine since the high-latency nature of network traffic is well suited to asynchronous, callback-oriented event systems which are themselves inherently functional.
My own RPC system enforces continuation passing style exclusively to unify the calling and return-value semantics. With this functional pattern in place it was pretty straight forward to transparently wrap arbitrarily many closures arbitrarily deeply in callback argument lists and method requests (which are the same thing under continuation passing style).
Where design patterns go wrong is in being a description of how to build a wheel (so you don't have to redsign the wheel) - what you really want is a wheel (so you don't have to rebuild the wheel).