This isn't unique to Haskell by any means, but it's the only real complaint I have about Haskell as a language for non-toy projects. The benefits definitely make it my go-to language. It's hard to list them all, but by far the nicest feeling is the correctness: when your code compiles, 60% of the time your program works every time. (Not to imply that tests aren't necessary--QuickCheck is great for that.) It's an otherworldly feeling to write a program not in terms of what to do, but what kinds of filters you want to put on something, and have it just work (and either stay working, or break future compiles if something's changed!) after compiling 10 lines of code, when you would have written at least 50-70 and had to debug it in almost any other language.
Edit: I'll add another complaint: Haskell is like C++ in that it's incredibly easy for a codebase to become completely unmanageable if your team doesn't have a common style/discipline. Go is a nicer language for "average"/"enterprise" teamwork, I think, since it almost forces you to write programs in a way everyone will understand. If you're in a team with good programmers that you trust not to abuse the language, this is a non-issue.
Edit: Okay, another one: If you change your Types.hs, the recompilation can take a long time in a large codebase, similar to C++. But GHC/Cabal keep getting faster.
Think that's it.
It's not noticeable in general, since only the Types.hs affect many different files, and they're rarely changed. Also, 99% of the compiles are partial, i.e. only the files that have changed (or dependencies of them) are recompiled. Partial compiles don't feel slower than ones on my smaller Haskell projects.
Is it annoying compared to e.g. Go? Definitely. But it isn't ruining my life. And there's a lot of optimization, fusion particularly, that goes on in the background.
If it's just me making something, 99% of the time I'll pick Haskell, unless I know everything that I'm going to do is mutate a hash table or array, in which case I use Go. (Not that that's not doable in Haskell, it's just not as intuitive/easy to do efficiently. Keep in mind that I said "if it's the only thing"--Haskell's downsides in this area aren't significant if you're also doing other things, and especially so if just some of those things are pure/don't have side effects.)
The reason why I say "if it's just me" is that Go is much nicer to use in normal teams. To me, it's a Java/Python/Ruby/JS competitor. Let's face it, a lot of enterprise teams aren't as disciplined or as good at/interested in programming as they could be. For this, Go is perfect. You could read that as "Go is for average programmers", and that is true--in a good way. It's extremely easy to pick up for new members of the team (Haskell is very hard, I have to admit!), everybody can collaborate without asking a lot of questions, because of 'go fmt' there's never any indent wars, and it's a snap to compile and deploy binaries.
If I have to do anything like map/reduce/filter, really any kind of operation on a set, I hate using Go. But it's not Go that I hate; it's most imperative languages. I don't want to specify how to do all of that, much less repeat how to do it. (In Haskell you can actually run into performance problems pretty easily because you've gone overboard with filtering sets in ways that would have sounded alarm bells in imperative languages.) Granted, languages with generics are better for this, and to me it's the major thing Go has to gain from generics--but as you implied, I just enjoy the "freedom to think about important things" that you get when you're thinking about results and not operational steps. It's unfortunate that it's so hard to know what this feels like without actually picking up a functional language.
When friends ask me which language to look at, I say "get to know Python, then learn Go" nowadays, mainly because pointers and pass-by-value can be a little hard to understand. Go is a great Python replacement. Web applications and APIs/backends I've particularly enjoyed implementing in it. Haskell is for when you've spent so much time coding in imperative languages that it's all boring, and you want to step into an interesting, but extremely frustrating (at first) new world.
A lot of people say e.g. Haskell would be as easy to pick up if it was your first language. I don't think that's true, if only because of the amount of syntax you have to learn--Scheme is probably better--but I do wish I could go back and try.
I do hope I can advertise it at some point, as the "Haskell in Industry" page is sorely lacking non-finance companies, and I'm sure there are a lot of companies out there using it.
If you want to see where Haskell is being used in industry, check the Haskell in Industry page out: http://www.haskell.org/haskellwiki/Haskell_in_industry
And if you really just want to see what it is like for game development, check out Frag: http://www.haskell.org/haskellwiki/Frag
Haskell is very well suited to large applications in my personal experience. My feeling is that it is actually worse for small-scale applications where you don't need the type system guarantees it provides.
I tend to disagree with this. Yes, GHC is a large application and most certainly developed by experts, but it's also a project with a very long history, whilst Haskell (language, extension, conventions,...) have changed over the years, and this shows in several places.
Next to that, GHC code isn't very idiomatic at times (e.g. for performance reasons, or because it can't depend on too many external high-level libraries).
Go seems to have been used in lots of networking-related scenarios, but I have yet to see either a major graphical application or even well-known open source game written in it yet.
I would love to see what the architecture of a 3D renderer looks like in Go, as an example.
Like you, I also share the same interest with Haskell.