I would definitely not like to have to use
Monoid.append Arrow.filter Monad.filter Monad.map
...just on grounds of verbosity. Too many characters = ugly code.
I think that depends a lot on individual taste and what you're used to. The above looks fine to me (and I use that style exclusively in my own code, except infix operators). It would also probably look normal to any python programmer. Even though python supports both qualified and unqualified, the default is qualified, and it's what people are used to.
But the alternative - to use short module aliases - does not scale well. I need to add appropriately qualified import statements to every single module in my project. We can't reexport qualifications.
Well, you do have to explicitly import every module you use, but that's true of unqualified import too, so I'm not sure what the not scaling part here is. Do you object to the idea that you have to give each module a name by hand and nothing stops you from being inconsistent about the names you give one module? I use the complete module name with a few exceptions, but even with that I sometimes have to put a bit of redundancy in module names to not conflict with a similar name in a neighbor package. Re-exporting qualified names doesn't seem like it would help... you'd still get name clashes unless it was done python style like Mod1.Mod2.f, but that's even more verbose. However, in a module that pulls together a lot of other modules using just one or two functions from each (which is the one likely to do lots of intra package imports and get clashes), I like the extra verbosity. The wider the scope of a name the longer it can be. It seems to scale just fine for me, and I have modules that import 40 or so other modules... in fact the more you import the more I appreciate qualified names.