I'll add one thing to your point - multimethods are a fantastic example of how Clojure allows you to structure programs in functional way that takes a programming feature (in this case polymorphic method dispatch based on the arguments at runtime) to the nth degree.
In Java and many other languages that have polymorphic method dispatch - the dispatch value is usually the type of the object for whom the method is being called on. Functional languages like Haskell take a much more powerful and expressive approach to this and extend it to matching the dispatch values for the called function on the type or pattern matched value of any argument.
Multimethods are essentially Clojure's take on this in a dynamic language. They allow the programmer to define a function that constructs the dispatch value however it wants - usually from the arguments given as input, in any order, on any condition.
To illustrate, I'll give an example I showed my wife yesterday. She's writing a roguelike game in ClojureScript at the moment that you can play in the browser - naturally she needed a way to represent the game world and the players position as they move around.
So, for illustration I'll omit the code for the world state, but she needed to bind event listeners for the keyboard to properly dispatch the proper movement logic. So the code she wrote looked like this:
https://gist.github.com/aamedina/8114944
She came to me with this code with the following problem - how do I think she should organize it? Clearly the handling logic is going to be more complex than a single line per direction (:up, :down, :left, :right) could handle, she has to account for terrain differences, buildings, monsters, what have you.
So I suggested using multimethods to accomplish this. This is what the multimethod solution I cooked up would look like in this case.
https://gist.github.com/aamedina/8114949
Now she has room in those multimethods to handle the potentially complex logic needed to make those arrow keys move the character properly. But another effect of this is that it hides the underlying state mutation from the implementation.
Now your move functions are pure and isolated from the coords atom, in addition to the fact that multimethods made the logic more organized, at the expense of a few more lines of code.
edit: moved code to gist
That said, in the example you posted I don't think you are using all the power of the multimethods, because you did not replace the case statement. You went from a case statement to a multimethod+a case statement. In this case, why not let the mutimethod dispatching to do all the routing/case functionality for you? Just use (.-keyCode e) as your dispatch function and use the different values of KeyCodes.XXX for each implementation of the multimethod. And you can even add a :default implementation that leaves the coords untouched.
In my experience the natural use of multimethods arise when you can choose the dispatch function for an element based on either some piece of data from the element or a computed value derived fron the element. But if you have to rely on case/cond/if statements the value of the multimetod is lessened, as you still have to touch your dispatch function when your hierarchy of values change.
edit:typos in the code
A typical case where a more complex construct does not help much.
Generic functions were introduced into Lisp, to replace a complex message sending mechanism with a more functional notation.
If the logic would forever stay a one liner, "increment the y coord!" when the up arrow key is pressed, I would agree with you - keep the case statement and go on your merry way. But that isn't the case, and my wife anticipated that being the case, hence the motivation for her question.
Spreading out complex logic into separate functions is usually considered good form. Like every design decision, you have to be wary not to overdo it - but I think my wife was spot on in identifying the need to do so in this case.
Putting the case statement aside for a second - you're also overlooking the fact that by using functions in this way the implementation becomes pure. The functions do not mutate anything and are completely oblivious to the fact that they are being used to swap! out the current position of the player for another.
Some benefits to writing pure functions include easier testing (you don't have to supply an atom to know if your function works, just call the function) and REPL use is vastly simplified. Additionally, I don't even need a browser or a keyboard handler to see if my movement functions work.
First version here: Uses only a case statement to dispatch the proper behavior, but as a pure function.
When she begins to take the state of the map and all of the other variables into account, this case statement will prove confusing to wade through - because it's one function that is doing four related but separate tasks. So version two is what you'd likely end up doing after the code got too unwieldy.
Oh wait... that's what a multimethod is! Now you've gone full circle. I hope you can see the point I was trying to make more generally, beyond the limited example I gave here.
(defn f [& args]
(apply g args))
Well done, you found some bad code written in Scala. I can assure you I've seen far worse in Python.
(You could also generate exactly this code with macros, which were a new feature in scala 2.10; I imagine a newer version of the code will do that)
Pointing to this kind of stuff as an example of scala shows a complete misunderstanding of the language quite honestly.
Lightweight data modeling is important and Java is truly terrible at this. I illustrated this in a gist about creating and iterating over a list and a map, and contrasting that to the equivalent Python: https://gist.github.com/amontalenti/8114359
The author says about Scala: "Due to its highly detailed static type system, Scala attracts the kind of programmers that like to carefully categorize and enumerate all the possible data structures."
It turns out, this describes expert Java programmers very well, too -- so it's no surprise that Scala is a very popular language with Java programmers. I'm finding that Clojure is the more attractive language if your sensitivities lean toward the "simplicity" and "dynamism" camp. I was reading some Scala code being used in production at Twitter and found this marvel: https://twitter.com/amontalenti/status/410977749629546496 -- you would simply never see anything like this in Clojure or Python codebases.
The point about multi-paradigm is interesting. It's very true that Clojure, unlike Python, does not support true multi-paradigm. Then again, Python does not support "true" functional programming. It's close, but no cigar, due to the lack of full-featured lambdas / blocks. If you have to pick one paradigm, functional is definitely the simpler and more essential one.
Illustration: imagine a variant of Python that forced all code to live in classes -- ick. But imagine a variant of Python without classes -- that's not so bad.
It's worth reading about Clojure's take on object-orientation-atop-functional using multimethods and hierarchies: http://clojure.org/multimethods