When people claim that Haskell is not newbie-friendly, their number one complaint is usually its "symbolic syntax" (which are actually normal functions and not syntax), and their number two complaint is usually the fact that Haskell is full of "mathy" words like functor, monoid, and monad. The first aspect is certainly something that is understandable to take time to get used to, but in the end the ability to define custom operators is a big feature. The second is what I want to talk about today.
In some respects, the complaint is baffling. Programming is full of jargon. What's a floating point number? Why are the more precise ones called "double"? What's a pointer? A reference? How are they different? If a pointer is different from a reference why do we dereference pointers? Why is it that people accept these terms as entirely reasonable, but then run as fast as possible in the opposite direction when they see the word "functor"? I have a couple ideas.
One explanation is that people have internalized most of their existing jargon, and don't realize that those words used to be unfamiliar. In that case, these people could use some additional reflection on what they've already learned and what they are learning now.
Just yesterday, I was trying to place some video clips next to each other to make a comparison GIF. It's surprisingly difficult to find a video editor that lets you do this. Most editors assume that you just want to play your video clips one after another, maybe with transitions in between. But putting two clips on screen at the same time? No way!
Eventually I found out that Lightworks could do the job and had a free version, but there was just so much that was unclear to me. What is a "sequence"? "Cut points"? What do "Trim in" and "Trim out" do? Everything was unfamiliar. That's not really a mark against the software. Now that I've done the job once I know where to look and what tools to use. Jargon isn't bad; it just takes some time to get used to. On the other hand, the fact that all the materials explaining that jargon are in the form of youtube videos was rather infuriating.
So if the complaint is merely that jargon exists, then my response would be to recognize that jargon exists everywhere, and it exists to facilitate efficient and precise communication. However, I think that usually the complaint goes deeper than that.
In fact, I expect that the real reason that people complain about words like functor is the same reason that the word was chosen in the first place. They have vague ideas that "functor" is used as a concept in category theory and they have the idea that category theory is crazy abstract nonsense that is beyond their comprehension.
This is demonstrated by the fact that often people suggest that Functor be renamed to something like "Mappable", or that Monoid be renamed to "Appendable". There are two reasons why this is a bad idea. First, these concepts are more general than the suggested names would imply. I would be surprised to meet a person who would agree off the bat that addition and multiplication are perfectly sensible notions of appending integers, while both are very clearly valid monoid operations. The second goes back to the reason that these are "scary" in the first place: they correspond to extremely well studied category theoretic objects.
I don't want to go into detail about how category theory relates to Haskell here. But in general it is good policy to believe that jargon exists and was chosen for a reason. It's not obvious to a layperson how chemical names work, but it wouldn't be reasonable to suggest that chemists overhaul that system to be more newbie-friendly. A person in the field will be an expert far longer than they will be a beginner, so experts should choose their language in order to facilitate communication with other experts, and outsiders should be able to understand that as a reasonable decision.
Rather than change the language itself, the solution should be to teach it better. Chemistry has the advantage that it is taught to most high schoolers. Category theory has no such prevalence. Furthermore, attempts to teach some of the abstract concepts on their own have been generally unsuccessful. But once again, that is emphatically not a reason to change the jargon. Instead, that just means that teaching and motivating abstract concepts is a difficult problem. The experts use the jargon because it's valuable, so the real problem is how to best communicate that value to beginners.