I'm a proficient Haskell user with some experience writing Haskell data science code. I also have experience doing the same in Clojure, though it's about 2 years out of date. I'll begin with Haskell then compare.
---
I find that purity is a valuable feature of Haskell but, more so than with other code, I feel a big divide between current practice data science and pure functional code.
Haskell has a strong base of financial code which is usually unavailable publicly, but it does lead to a lot of blog posts and commentary describing how you can build highly efficient, powerful streaming systems in Haskell which interact with Excel. This is largely true as laziness tends to put people in a streaming mindset quite easily. Finally, there's a big push in the pipes/conduits camps to reify streaming as a first class action which can be manipulated easily. I'm a big fan of pipes—I think it's completely unreplicated anywhere else.
Haskell tends to be a memory hog and can produce space leaks if you're not careful. This will decimate your ability to use it for large data sets, but it's easy to avoid after you get a little bit of practice in. In particular, it's worth learning where new laziness is generated (whenever you produce a lifted type) and making the decision as to whether that's correct or not. Strict data types and UNPACKing eliminates space usage and leakage quite nicely.
Haskell has san incredibly powerful and fast vector library—called vector, unsurprisingly—and I encourage you use it constantly. There are also a number of other very nice data science foundation libraries like ad, linear, vector-space, statistics, compensated, and log-domain.
Haskell's best dense matrix library, hmatrix, is nice but GPL. It also doesn't interact as nicely as I'd hope with vector. There's also Repa, though that's more optimized for images and parallel matrix operations like DFT.
Haskell's interactive runtime has a HUGE deficiency in that it erases all local variables on each code reload. I've been assured that there are proprietary (financial) REPLs which don't have this deficiency, so perhaps it could be eliminated if someone wanted to take it as a project.
If you have a GPU to spare then it's really easy (and fun) to push algorithms on to it using Haskell's Accelerate library.
Generally, static typing is a huge boon, but there's too little broad usage of Haskell as a platform for data science yet to see how best to use it. HLearn is a great test bed for a lot of this. I find it really exciting, but probably a bit too dense to be practical. There's a big hole in the ecosystem where a data.frame/pandas and ggplot/lattice duo could fit.
---
Clojure's primary benefits drive from, unsurprisingly, using functional algorithms atop Java's runtime and library support. I made a Clojure binding to JBlas a few years ago for my research (clatrix) which wasn't too difficult to build, but plugged a needed hole in the ecosystem. I also reimplemented a bunch of basic machine learning algorithms in Clojure for a class and found that it was difficult (3 years ago) to get good performance out of raw Clojure, even when using type annotations. I found that dropping down to Java types wasn't so painful, but felt incredibly non-native. I'd suffer massive performance problems to just not have to do it. Clatrix helped to solve that a bit and it's been developed much further due to core.matrix, though I've not used core.matrix in anger.
Generally when coding in Clojure I miss static types (though I've not yet used core.typed) which is entirely personal, so YMMV. I find them to be very, very key in statistical code, though, since so many error conditions just lead to difficult to interpret, yet totally false results. I want my errors to come from bad tuning, not uncaught type mangling.
I also did a fairly large amount of parallel processing in Clojure using map-reduce implemented atop the actor model. It worked pretty well and distributed over a few hundred machines, yet was never convenient enough to replace manually launching the jobs and collecting the results by hand at the end. After getting some experience with Erlang/OTP I think I could have done better, but it was still a boon as to how nice it was to do in Clojure.
---
Generally, I find static types to be a huge boon for statistical programming as noted above. It's a tragic thing when you lose sensitivity to surprising results due to general mistrust of your own code. Static types make me rarely mistrust the correctness of my code (and libraries like quickcheck and simple-check help to cover the remaining uncertainty!).
Haskell I feel is faster broadly... except when it's not. Space leaks and excess laziness will destroy performance, but I still vastly prefer programming in a lazy-by-default environment because it leads to better composability and reuse. It also provided a focus on streaming algorithms that I use frequently. Clojure's reducers are nice but don't even approach the power and sophistication of Haskell's pipes.
Clojure has better "obvious IO" library support in that its dynamic code requires less ceremony to drag down an online corpus. I've written a parallel website scraper in Haskell, though, and I feel that the concurrent programming would have been significantly more difficult in Clojure. Both have STM, but Haskell's STM is better.
Haskell has better general libraries, though, due to the library reuse made available by laziness and static typing. They can take a little effort to learn, but then become massively powerful with ease. Haskell also has the wonderful Diagrams library for building some kinds of charts, but it's more a substrate than an answer.
Haskell's vector data type is wonderful, and in both languages you can drop down to impure chunks of memory if your algorithm or performance needs are a fit for that. All you pay is expressiveness. Here again static types are a win as they can enforce impure regions and make sure that those regions don't mix and don't take over your program.
If I were to make my home in one of those languages for some serious data science, I'd do it in Haskell. It's still rough around the edges, but I feel there's a better substrate for building more sophisticated things atop it. Clojure may be able to solve your particular problem more quickly, but my experience is that quick things written in Clojure don't pay out over as long a period as quick things written in Haskell. Further, I think the comparative effort needed to build long-lasting libraries and tools in lower in Haskell.
If I were to just do a quick data science problem, I'd probably use R.
I'd also use Haskell for data science much more if it had a better REPL. IHaskell (a Haskell core in an IPython notebook) might become that needed REPL at some point.