Previous related applications (mostly written >5 years ago) were written in high performance programming languages like C/C++

I have to say in advance that I've never did some serious Haskell programming, but I don't think this statement is true. C is still the language of choice for this kind of tools. If you are capable of writing a high performance string matching tool, it will be quite trivial for you to make it multi-threaded. The guys in our department worked really hard for over a year on a very efficient suffix array tool, parallelizing it was a matter of weeks. Another reason to choose "high performance programming languages" when it comes to high performance computing is simply memory. I know RAM is cheep these days, but suffix arrays are demanding. For example if you want to search in the complete human genome, you'll need far more than 8gigs RAM with the most efficient suffix array implementations available.

C is still the language of choice for this kind of tools. If you are capable of writing a high performance string matching tool ...

I know that, and that is why I asked that question. Is it worth to spend >1 year coding a "very efficient suffix array tool" when (maybe) you can code it in less time being less efficient but in a language that supports parallel and concurrent computation (ideally) easily?

The point about memory is relevant, but I don't know if critical in this case (I'm not trying to build suffix arrays over strings of 3Gbs)

Well, in the case of suffix arrays, it's not the coding in C that makes it difficult or time consuming, the algorithms are quite complicated. The speedup you gain by using clever techniques and efficient data structures isn't in the range of 2,4 or 8, it is in the thousands. For example I know that if you'd use a simple qsort() for the suffix array sorting, you would need weeks for a human chromosome compared to minutes the guys need here.

You could also see it the other way: if you use C and maybe OpenMP, then the simple to implement, naive algorithms might be already fast enough.