This probably won't be well received, but I think posts like this, with lines like "a list of objects of type X is an element from the free monoid generated by the set of elements of X where the monoid structure (a unital associative binary operation) is given by concatenation", go some way towards explaining why functional programming won't ever become mainstream.
Not that you're saying it is, but it probably isn't ideal to use a programming language that is able to become mainstream. It seems likely that the ideal language should be (at least, at first) very difficult for an average mind to grasp. A language that inherently forces its users to be either 'naturally smart' or 'doggedly learned' will produce a better signal-noise ratio as a by-product: in open-source offerings, engineer-employees, and, at a micro level, within the engineer's code.
With that said, whenever readability is lost for the sake of ego, that is a loss. I'm not accusing the author of that though.
I don't think the problem here is functional programming, it's the author's over-eager use of category theory to describe something simple. In particular we're just talking about all possible lists you can create in LISP, so do we really need to resort to free monoids? The language of category theory is greate for describing complicated structures like tensors and sheaves and what have you, but in this example it's not really helping.
Epsilon-delta proofs are beyond me, but we still teach calculus in high school. Just because some parts of a field are esoteric without study doesn't mean the field is doomed to obscurity.
I know jargon looks unsurmountable at first, but if you pay close attention to definitions, they are usually extremely simple. To wit, the example you quote is just the set of strings on X.
