I am a bit confused about why you perceive that quote as elitist. To me it sounds like the opposite, namely that more experienced Haskellers should write their code such that it can also be understood by less experienced Haskellers. That should make the more advanced concepts more approachable even for people who are not yet part of the “elite”. Can you elaborate a bit?
Edit: This was a reply to a comment that has now been deleted.
Which quote exactly?
Can you think of a simple example of this for purposes of comparison? For as long as we have the difficult error messages, a gentle introduction to GADTs could perhaps help Haskell learners see where they are more appropriate than type classes.
I think we can just ignore it, it has been removed for a reason. I assume it was a misunderstanding. @ocramz please tell me if that is not the case.
No, it wasn’t a misunderstanding but I don’t feel like taking the conversation in that direction.
I feel pretty bad now and I am sorry that I am making you feel unwelcome and that I am perhaps draining your enthusiasm by starting this discussion, so feel free to ignore what I’m writing here. I will try to explain a bit more of my point of view.
The offending comment seems to be the comment by @ketzacoatl about “the wizards principle”. @Yakushima’s earlier reaction to it was also pretty unexpected for me.
First of all, the use of the words “wizard” and “mere mortals” is a bit playful. It is self-deprecating if you consider yourself part of the mortals and arrogant if you consider yourself part of the wizards (but I don’t think the latter is the case here). I personally would use more neutral terms like “less experienced” and “more experienced”, but I don’t think anyone can deny that those groups exists although they don’t have clear boundaries.
Furthermore, I do think it would be good to have better documentation and explanations for less experienced Haskellers. However, I do believe that explaining things is a skill that is not necessarily proportional to a person’s Haskell or general programming ability. And perhaps more importantly explaining things can take a lot of effort. So I wouldn’t blame for example Edward Kmett for creating libraries like hyperfunctions, which have practically no documentation. One the other hand he should certainly not be praised only because he writes such esoteric packages. If nobody can understand the libraries that you write then you haven’t really contributed anything to the community.
Admiring Feynmann as I do, I’ve spent eight months wondering whether my inability to explain GADTs reflects that I don’t actually understand them, that my teaching ability is severely limited, that they are really tremendously complicated, or something else. However, I have recently come across this passage from a video interview with Feynmann.
I’m not going to be able to give you an answer to “why magnets attract each other” except to tell you that they do. … I really can’t do a good job, any job, of explaining magnetic force in terms of something that you are more familiar with because I don’t understand it in terms of anything else that you’re more familiar with.
So I feel a bit better saying “I’m not going to be able to give you an answer to ‘why GADTs are useful’ except to tell you that they are. I really can’t do a good job of explaining GADTs in terms of something that you are more familiar with, because I don’t understand them in terms of anything you’re more familiar with”.
[I’m not trying to refer to anyone in particular by my use of “you”.]
That’s a lovely quote, thank you for sharing 
Well note that we aren’t using GATDs, and we actually only reached for more advanced extensions after getting stuck trying with the simplest approach. This strategy worked really well for us, and perhaps this kind of learning material is missing for GATDs.
Here is a concrete example of such documentation (but for OCaml): Writing a Game Boy Emulator in OCaml - The Linoscope Machine . The author describes how using variants was not practical, and why GATDs are a better solution for the problem.