In terms of theory, I found the "Applicative Programming with Effects" paper and the "Typeclassopedia" very helpful.
http://www.soi.city.ac.uk/~ross/papers/Applicative.html
http://haskell.org/sitewiki/images/8/85/TMR-Issue13.pdf
I started doing a real implementation of these data structures in Perl this week. (I say "real" because people have "added Monads to Perl" before, but they didn't really add Monads, they just added a "programmable semicolon".) Anyway, in doing so, I saw in great detail the relationships between the various types (specifically "liftM2 ($)" and "<*>"), and tried to generalize things as much as possible. The result was something like Arrows, and that helped me understand the "why" in addition to the "how". Writing test cases was also helpful to me; using these esoteric stuctures in "real code" helped me build up the intuition needed to advance farther.
Anyway, it took me three readings of the Applicative Programming with Effects paper to get Applicative Functors, and after that, Arrows were pretty easy. So I recommend that paper, and lots of poking around in ghci.
To bring this back on topic, yeah, it would be hard to teach this stuff to Joe Average. But a language that allows it is still important to develop. (I also learned firsthand that language design decisions to make it difficult to implement certain features. Implementing the equivalent of "instance Monoid b => Monoid (a -> b)" is almost impossible to do cleanly, due to the polymorphism of "mempty"; it's defined in Haskell as "mempty _ = mempty", and in Perl, we discard the type information before we have a chance to pick the "second" mempty.)
Yeah, you are exactly right. Programming languages need to be designed for the very best programmers -- they are the ones that need the productivity boost. For me, not understanding the language is never a problem. Making something "easier to understand" will not help me write software that goes together faster or ends up more reliable. It often has the opposite effect; Java's lack of ... everything, for the sake of simplicity, really slows me down. Comparatively, learning a new concept is much easier. If I start using a library that uses Arrows, I read the Arrow paper, spend a few days playing with it, and then I have one more tool that will help me be more productive every day for the rest of my life. Making a language that doesn't have arrows saves me reading a paper about them, but it wastes my time every day for the rest of my life.
So, "simple" programming languages -- do not want. I am not saying that you should start your "intro to computer programming" class with a long lecture about category theory, but I am saying that you should never hide things from people that want to know about them.