Most of what you say I agree with, but I take exception to your "lots of closures" comments.

I've had to maintain code with large doses of lots of closures. Once you know the basic ideas, it is no harder than any other code.

I would draw a parallel to OO programming. If you sit someone down who doesn't understand OO and have them try to learn a large OO system, they'll be lost. Just working out the basic mechanics of where to find the method that gets called HERE (and having an idea of when it matters and when it doesn't) is going to constantly stump them. The fault is not, of course, necessarily with the OO code or design. It is that the programmer in question is lacking the mental toolbox that you need to understand OO code. (Of course it is also possible that the code and design are both terrible.)

Practical techniques that use closures are similar. When you understand, "Oh, he's building up a dispatch table" or "Oh, he's creating an iterator" then suddenly the technique scales and it isn't a problem. Of course, as with any technique, it is possible to create a real mess with closures. But it is also likely that clean code using closures will look like a mess to someone who lacks the right mental toolbox to deal with them.

Note that in both examples what is key is chunking, being able to understand what a block of code is doing so that you can know during maintainance whether you need to dig further there or look elsewhere.