1. Elm encourages highly-rigorous state handling, thanks to the React-like "Elm Architecture" https://github.com/evancz/elm-architecture-tutorial/ and features like the Maybe type and ADTs. I rarely worry that I've overlooked some horrible, asynchronous corner case or that something might be null.
2. The Elm architecture requires a considerable amount of boilerplate code, at least relative to something like Ember.js. It's often necessary to thread significant amounts of application state through parameters, for reasons similar to the ones here: https://docs.google.com/presentation/d/1afMLTCpRxhJpurQ97VBH... But when you combine that with the need to use "case" matches everywhere to destructure ADTs, and the fact that you can't define guard expressions (or destructure things nested inside record types), it tends to result in a lot of extra typing.
3. The Elm tooling is a mixed bag. The error message are the best I've ever seen, but the sweet time-travelling debugger just refused to run when I tried to use it with the Elm architecture tutorials. This pattern of brilliance and brokenness feels fairly pervasive at this point.
4. The Elm community can occasionally be a bit frustrating to work with as an outsider. Sometimes, when I run into an issue, I eventually find a GitHub discussion like this: https://github.com/evancz/start-app/pull/37 , where somebody is trying to address an actual issue (one that was biting me, too), and the community is more-or-less throwing up its hands. Also, the Elm community has an occasionally surprising tendency to close GitHub issues quickly, even if it's known that they'll probably need to fix something someday: https://github.com/evancz/start-app/issues/35#issuecomment-1...
5. For me, Elm feels considerably more restrictive than programming in Haskell.
6. Elm's type checker and design do have one huge payoff: Even very complicated apps with lots of tricky asynchronous state tend to work on the first run after they make it past the type checker. This is hugely valuable, and it makes me more inclined to forgive Elm's limitations elsewhere.
Overall, Elm is exploring some really important ideas, and it's pushing the general React-style architecture to its logical limits. I think I'd consider it for small- to medium-sized apps with lots of tricky state, and with developers who are strong at functional programming.