This is a complex problem. There are multiple causes and different people find it hard for different reasons. Here are a few that come to mind for me, in no particular order.

Incidental Complexity

One important effect, unrelated to the design of the language, is the incidental complexity imposed by existing tools. For example, having an interactive prompt to get immediate feedback by running Haskell code helps—and Haskell does. But ghci is quirky. Some of the quirks are necessary and some are historical, but both kinds can make learning Haskell more difficult.

As an example of a quirk that's not necessary—but, by now, so entrenched that it's hard to fix—is how ghci relies on the Show class to display results. Now, relying on some typeclass is great: it makes it easy to customize how things get displayed. But Show is the wrong class to use. Ostensibly, Show is about lightweight serialization and deserialization, not human readability. It's supposed to print out valid Haskell code and can't work for certain values like functions. Values in ghci can be pretty unreadable:

λ> "∀n∈ℕ." 
"\8704n\8712\8469." 

and if you try to evaluate a function—a perfectly reasonable thing to do—you get an annoying and unclear error message:

λ> show 
 
<interactive>:17:1: 
    No instance for (Show (a0 -> String)) arising from a use of ‘print’ 
    In a stmt of an interactive GHCi command: print it 

Not a good way to teach people!

This could be fixed by adding a Display class to Haskell—similar to other languages with multiple string representations, like Python—but at this point, that would be a massive undertaking because of legacy code and backwards compatibility.

Less avoidable problems with ghci include the dreaded monomorphism restriction¹ and the fact that ghci accepts a weird sort of syntax that doesn't match up with Haskell code in files. This second problem cannot be resolved completely because you want to be able to evaluate expressions, IO actions and definitions directly in ghci, but it could still do a better job of supporting normal Haskell syntax.

Other tools have problems of their own or are just plain hard to install. (IHaskell, a Haskell kernel for Jupyter notebooks, is a great example: it fixes numerous ghci issues but is a real pain to build and install so I hesitate to recommend it.)

As a whole, this is probably the obstacle that's the easiest to address—but also requires tedious work across multiple projects. There's progress being made on this front, but it'll never go away completely.

Foreignness

One thing to keep in mind is that the vast majority of people learning Haskell are actually learning functional programming with Haskell as a conduit. That's more than just picking up a new language, so we should expect it to be harder! I posit this is actually beneficial: it means Haskell is worth learning to broaden your intellectual horizons and not just as yet another practical tool.

But it skews expectations. It did for me. When I was first picking up Haskell, I already had exposure to something like ten different languages, several in depth². Learning an additional language was easy, almost systematic. And no surprise: most of the languages I knew were similar. They had variables and statements and loops and objects and all these shared ideas… Haskell didn't. Beyond arithmetic operators. everything was different.

Haskell is different. It has different syntax and different concepts. It requires different idioms and a different way of thinking. And people, all too often, spell "different" as "difficult".

Reputation

Haskell has the reputation of being difficult and reputations tend to reinforce themselves. People come in expecting it to be difficult, and have a subconscious excuse to give up when things get rough. Chances are that you'd get stuck at some point in learning anything new, but if you're expecting it to be difficult you'd be more likely to lose hope and just reaffirm your expectation.

This reminds me of an anecdote from a math grad student I knew. He used to teach advanced mathematics at a summer camp for young children. He would get them to solve difficult problems by not telling them they were supposed to be difficult—and they would do it. Having the expectation that something is difficult. Having the expectation that something is supposed to be hard can have a real effect.

Teaching Materials

Haskell has a wealth of teaching material available online—but the quality varies wildly. Worse, there's no easy way to tell which resources are good and which are either outdated or actively bad. People end up either picking something at random from Google or going by others' recommendations which can be pretty inconsistent. (And, of course, a resource that worked for one person might not for another.)

There's a distinct lack of a unified resource with a coherent lesson plan. While I've learned lots of things—lots of programming languages, pertinently—through haphazard online tutorials, this is a style that does not work for everyone. Some people would really benefit from longer, well-organized books or even full-on courses with lectures, notes and exercises. Unfortunately, there's no easy place like this to send people.

The state of teaching materials has generally been improving. A recent course at UPenn was indeed well-organized, and made most of its resources available online—including a set of notes with interactive runnable examples. (The runnable examples are part of FP Complete's School of Haskell, another new educational resource.)

But, with all the improvements and new options, it's even harder to find something that works for you. There are countless tutorials, more and more books and, ultimately, little organization. There's also a widely acknowledged "intermediate problem": it's easy to find tutorials for beginners and there's plenty of options for experts, but surprisingly little bridging the gap.

All this makes it harder to pick Haskell up and easier to get stuck.

Level of Abstraction

Appropriately enough, this obstacle is itself somewhat abstract. Basically, Haskell—the language, but especially the libraries—requires thinking at a higher level of abstraction than any other languages I know. This is a big part of its appeal, but it's hard!

I think there's a strong parallel between how people find learning Haskell difficult and how people find their first rigorous, abstract math class—often linear or abstract algebra—difficult. It requires a new way of thinking and a new set of meta-skills: the ability to reason about concepts that apply in many different contexts, the ability to both come up with useful metaphors and not be misled by them, the ability to grow an intuition from a definition and some examples.

Working with high-level abstractions is a skill in and of itself, and often yet another thing somebody has to pick up to learn the language. (I think the difficulty people face with monads is a symptom of this issue.)

As a whole, I think things are getting better. Haskell is markedly more accessible now than it was five years ago. More people seem interested too, although it's hard to gauge causation—in either direction. Hopefully, it's a virtuous cycle: as more people get involved, the learning experience improves and as the learning experience improves more people get involved.

footnotes
¹ That's what people actually call it in the community, DMR for short :). It's a necessary part of the language—not having it would cause as much confusion as having it—and ghci turned it off by default, which helps, but it's still an obstacle. Just look at how a small cottage industry has popped up for answering questions about the DMR on StackOverflow!

² I really enjoyed learning languages back then. In fact, that's how I learned to program: every half year or so I'd pick up a book about a new language and learn it, incidentally picking up language-neutral ideas about program organization. In hindsight, it makes sense why I ended up so enamored with programming languages as a field in college—I already liked it back then, but never realized it was a legitimate thing to study on its own.