Although I don't disagree regarding the difficulty of understanding Cofree, at least the blog post explains what it's doing in this context. That alone was enough for me to understand that beginning snippet, convince me that there was at least some utility in the use of Cofree here, and remember this as an example of where it can be useful.

The parent^2 comment also snipped an example explained in the blog post, where he specifically chose that structure so that he could make use of built-in structures to traverse the tree. Similar to the use of Cofree (though I understand the Traversable monad far more), the reasoning was presented, it made sense, and I could move on from that without scratching my head.

You don't need to understand category theory to understand Cofree. It's not a very complicated construction. The Haskell ecosystem's provision of stuff like Free, Cofree, Fix, etc. covers a huge number of common constructions and saves you a lot of effort.

A common example of a "kind of hard problem" I see all the time on various tech sites (e.g. here) is flattening a rose tree (arbitrary depth nested array). Guess what? In Haskell, you can express the whole structure as "Free []". Hundreds of useful primitives are already written for you, including the thing you need to flatten the tree, "toList". This just goes to show that it's not a pointless masturbatory excercise in dragging math into software engineering; it's actually directly and immediately very useful.

Someone not understanding how to flatten a tree (or what have you) to having to understand Free is a huge jump.

I think this is more a failure of documentation than anything else. The definition provided there is correct and useful for a certain subset of people, but there are ways of grokking comonads and cofree comonads that don't require so much math.

It's a tricky concept no matter how you slice it (in my opinion), but I like the following article:

http://dlaing.org/cofun/posts/free_and_cofree.html

I won't claim it's easy reading, but it's a lot more grounded and motivated.

I belive that abstraction can be a double edged sword.

Pro. you write less code Pro. Your code is easier to read for everyone familiar with the abstraction. Con. You need a math degree. Con. Harder to get contributors. etc...

Tangentially. The docs also say that:

"In practice, cofree comonads are quite useful for annotating syntax trees, or talking about streams."

Sometimes you can learn the abstraction and one of its particualr use cases. And apply it when you find it, without needing the degree.

Also to answer your question: "So I take it you believe that a degree in category theory is the bare minimum for people to expect to be able to understand other people's code?"

No, I don't believe so.

But the experiment of forming a team of people that knows all this to see how productive they are, would be nice to see.

This kind of language sounds intimidating if you aren't familiar with it, but it's actually not that complicated. The documentation states the universal property of the cofree comonad for a functor. You don't need a degree in math to understand it - the bits of category theory that most Haskellers use are very basic.