I agree with you on namespacing: I've found myself having to add prefixes myself when working with a bunch of similar datatypes with identically-named constructors (e.g. terms and types in a compiler have many similarities).

Saying "non-argument" and ending it there is not useful, but in this case it's shorthand for something along the lines of "not even wrong", and I think that's a valid answer for some (not all!) of the points in the OP.

To pick one example: the author gives an example of an eta-reduced function and then says:

    let fn1 a b c d = ... do something ...
    let fn2 a b c = fn1 a b c
    fn2 a b c d

> and you're like ...wtf... where the hell does d come from.

(Or their criticism of partially-applied functions, which is essentially the same thing.)

This is a "non-argument": the only thing that is being made clear here is that the author hasn't spent sufficient time learning the idioms of an unfamiliar style of programming. Yes, horrible partial-application like

    f = (g .) . ($) . (. (. h))

or whatever is always a bad idea, but saying that writing

    map f

is always worse than

    map (\x -> f x)

is much more likely to be a symptom of unfamiliarity than a deep, cutting critique of functional programming style.