Recs.
Updated
SpecsUpdate
Pros
Pro Statically typed
Haskell's type system is extremely expressive. Often, it is clear how a function should be used from only looking at its type signature. Thanks to full type inference, this seldom gets in your way though and there's generally no need to declare the type of any local variables.
Pro Pure functional language
Perfect for learning what it really means to use functional paradigms.
Pro Mathematical consistency 
As Haskell lends itself exceedingly well to abstraction, and borrows heavily from the culture of pure mathematics, it means that a lot more code conforms to very high-level abstractions. You can expect code from vastly different libraries to follow the same rules, and to be incredibly self-consistent. It's not uncommon to find that a parser library works the same way as a string library, which works the same way as a window manager library. This often means that getting familiar and productive with new libraries is often much easier than in other languages.
Pro Highly transferable concepts
Haskell's referential transparency, consistency, mathematics-oriented culture, and heavy amount of abstraction encourage problem solving at a very high level. The fact that this is all built upon little other than function application means that not only is the thought process, but even concrete solutions are very transferable to any other language. In fact, in Haskell, it's quite common for a solution to simply be written as an interpreter that can then generate code in some other language. Many other languages employ language-specific features, or work around a lack of features with heavy-handed design patterns that discourage abstraction, meaning that a lot of what is learned, and a lot of code that is needed to solve a particular problem just isn't very applicable to any other language's ecosystem.
Pro Extremely robust for refactoring
If some interface / data structure needs to be modified, even if it's a rather intrusive change in a large codebase, type inference keeps most of the code working as-is, and the compiler will reliably point out the places where it would fail. The strong types make it easy to figure out how to fix those problems.
This allows quick prototyping without needing to worry too much about long-term design, and it makes Haskell largely immune to legacy-cruft problems.
Pro Easy to read
Haskell is a very terse language, particularly due to its type inference. This means there's nothing to distract from the intent of the code, making it very readable. This is in sharp contrast to languages like Java, where skimming code requires learning which details can be ignored. Haskell's terseness also lends itself to very clear inline examples in textbooks, and makes it a pleasure to read through code even on a cellphone screen.
Pro Popular in teaching
Haskell is really popular in universities and academia as a tool to teach programming. A lot of books for people who don't know programming are written around Haskell. This means that there are a lot of resources for beginners in programming with which to learn Haskell and functional programming concepts.
Pro Referentially transparent
Haskell's Purely Functional approach means that code is referentially transparent. This means that to read a function, one only needs to know its arguments. Code works the same way that expressions work in Algebra class. There's no need to read the whole source code to determine if there's some subtle reference to some mutable state, and no worries about someone writing a "getter" that also mutates the object it's called on. Functions are all directly testable in the REPL, and there's no need to remember to call methods in a certain order to properly initialize an object. No breakage of encapsulation, and no leaky abstractions.
Cons
Con Very difficult learning process
For people unfamiliar with functional programming, it's a difficult language to learn.
Con Basically has no foothold in industry
Nearly 30 years of existence and basically no application effectively in use. (Apart from some mini apps smuggled in by Haskell evangelists, that will disappear once they leave the company). Although, this is slowly changing in the last years.
Con Rigid pure functional only
It's a wanted limitation to prevent potentially bad code, however it also takes away choices in how you want to code.
Also being a pure and rigid functional language, it can take some time to become accustomed to the language, and until some has had a lot of practice and experience with Haskell, they might feel unproductive.
Con Rejecting community
Unhelpful for newcomers, rejection of any new ideas, haughty and academic people.
Con Obscure ugly notation
0 = 1
Using "=" like this: <code>
-- Using recursion (with pattern matching)
factorial 0 = 1
factorial n = n * factorial (n - 1) </code> Example from https://en.wikipedia.org/wiki/Haskell_(programming_language)
is quite simply annoying aesthetics.
Con You need some time to start seeing results
Haskell's static typing, while helpful when building a project, can be positively frustrating for beginners. Quick feedback for errors means delaying the dopamine hit of code actually running. While in some languages, a beginner's first experience may be their code printing "Hello World" and then crashing, in Haskell, similar code would more likely be met with an incomprehensible type error.
Con Symbols everywhere 
Haskell allows users to define their own infix operators, even with their own precedence. The result is that some code is filled with foreign looking operators that are assumed to be special-case syntax. Even for programmers who know they're just functions, operators that change infix precedence can potentially break expectations of how an expression is evaluated, if not used with care.
Con Disconnected from von Neumann architecture
Compiler need to translate to imperative low level code.
Con Language Extensions lead to unfamiliar code 
Haskell's language extensions, while making the language incredibly flexible for experienced users, makes a lot of code incredibly unfamiliar for beginners. Some pragmas, like NoMonomorphismRestriction, have effects that seem completely transparent in code, leading beginners to wonder why it's there. Others, like ViewPatterns, and particularly TemplateHaskell, create completely new syntax rules that render code incomprehensible to beginners expecting vanilla function application.
Con Written for theory rather than practicality
Intended as a 'model' language rather than something that is supposed to increase productivity/efficiency.