It's not wasteful, it is just putting the "logic" into the pattern matching at the function selection level. In Erlang you can usually take the first level of case/if statements or arg parsing and put them into the function definition. You do end up repeating certain patterns when defining the function head, but it lets you get away with a lot less repetition in the body of the function.
Different strokes I guess, but in my experience I found myself repeating code a lot less in Erlang due to the functional nature of the language and because it made certain bits of repetition in the code more obvious due to the "shape" of code in my editor.
I'm guessing your example is a matter of factoring and how/if the frameworks/libs suite your needs. Rails provides DLSs which have just the right interface to allow you to not repeat yourself in many use cases. If your erlang libraries do not, thats a function of the lib/frameworks, not the language.
In terms of "suiting my needs", that's an example from mochiweb itself, so my needs have nothing to do with it.
In terms of refactoring... I've seen code like that scattered through Erlang often enough to have a slight dislike for it (it is not a Major Problem with the language, and pattern matching is elegant).
And to some degree - it is a function of the language:
foobar(a, b, c=1) ...
is a lot less code than
foobar(A, B) -> ...;
foobar(A, B, C) -> ....
So I will stand by my statement that Ruby is generally more succinct than Erlang, which is something that strongly pushes me towards using Ruby for most things, and Erlang only where it really shines.
I don't dislike Erlang - quite the contrary - I first encountered it professionally in 2003 and have dabbled now and then with it. I just think it can be a bit "uneven" - which makes me think it will likely never catch on as a very widespread general language.
And I don't believe in "the right tool for the job" - most people are going to know a few languages (at best) and stick with them, because for most things, it's cheaper in terms of overall effort to do something with a language you know than doing it with something you don't and have to learn (also likely not doing as good a job, because you're new to it), even if the result isn't perfect. So languages that are niche only, in my mind, are probably going to be less popular than they could have been if they were more general purpose.
If you're not matching on variable numbers of arguments, you can just have 1 function sig and a case statement.
The thing I dislike most about erlang, besides the lack of a good macro system, is that the repl is full of annoying special cases, so you have to actually stick your code in a file with a proper module name and compile it in order to test stuff :(
