In my experience the "category theory" claim is imprecise but not unfounded. Without fairly serious abstract understanding of monads, functors, and applicatives (at a bare minimum), it is not possible to write Haskell code profitably. By that I mean that without such knowledge you should have just written something else.

To make Haskell a serious advantage and not just a minor benefit (compared to, say, SML), you probably also need to understand kinds. Let's bear in mind that the vast majority of practicing programmers can't reasonably define an algebraic data type, and that it's not their fault, because the ROI for learning such things is often negative.

I do think there is a reactionary "don't-wanna-learn anything" vibe against Haskell among certain groups. But I think we should be clear that, to get the power that Haskell promises, you do need to learn many new things. Those things, while not exactly category theory in a narrow sense, are closer to category theory than they are to conventional programming knowledge.

Yes, it is completely unfounded. You do not need to know anything about category theory, or even what it is. All you need to know about Monad is its interface. If you can handle java, you can handle haskell. All you need to understand with kinds is "its how many arguments a type takes". And that isn't category theory in the first place. Anyone can define an ADT. That's one of the first things I taught our PHP team, nobody had any confusion or problems with it, it was a 2 minute thing. I have a hard time imagining how you could think:

    data Bool = True | False

is hard to learn or understand or woulf have a "negative ROI".

As a PL enthusiast that likes to dabble in different paradigms and basically learns a programming language or two every other year by far the hardest language to wrap my head around has been Haskell.

There are a few reasons for this that get dismissed by the day to day practitioners. First, there is the cognitive rewiring required to think of everything as an inert expression. In Haskell there are no actions, just descriptions of actions that the runtime manages. I'm specifically talking about I/O and its monadic implementation. Second, learning about monads is not enough. When effects are encapsulated as monads you need to understand monad transformers to fruitfully combine effectful computations. This is by no means the best way to do things because there are also implementations of effectful computations with row types and extensible effects, e.g. PureScript, that requires a lot less cognitive overhead and is less error prone. Third, many of the high-powered libraries in the Haskell ecosystem are so heavily reliant on categorical constructs, e.g. free (co)monads, functors, applicatives, monoids, bifunctors, Kleisli categories, etc. that getting through all that thicket to be truly productive with the libraries instead of just copying and pasting requires a time investment that is of dubious value to many programmers and you're better off learning about security practices on OWASP because you are more likely to encounter a SQL injection than you are to encounter a Kleisli category of a monad.

I'm not saying knowing these things is not useful or won't make you a better programmer but to just demonstrate that there is indeed a cognitive overhead that might not be worth it. I like category theory as much as the next mathematician but programming with categorical constructs is not necessarily the most optimal way to do things when all I need is a screen scraper for an XML feed.