Perhaps it is just different kinds of cognitive overhead.

The purpose of writing point-free functions is to encourage thinking about chaining functions together instead of considering what really happens to low-level values. It's like using pipelines. This means that for debugging, "stepping through" wouldn't help you much IMO even if you could do it![0] (A whiteboard might help, though.)

I'll try to give an example: if you're looking at an unnecessarily point-free expression like "mapReduce = (. map) . (.) . foldr1", the logic is difficult to read. I'm not an expert in point-free-fu yet, so in that case I'd recommend pointful[1], which deobfuscates that expression to "mapReduce x x0 x2 = foldr1 x (map x0 x2)", a map followed by a fold. So the problem is again reduced to looking how functions are being chained together. For larger examples of point-free expressions I'd try to isolate individual functions as where clauses.

[0] As mentioned by cgmg, the Writer monad is useful if you need to know the values going in and out of functions. [1] http://github.com/23Skidoo/pointful

I really wouldn't underestimate this. Formal proofs and verified programs pretty much always involve functional languages at the core because there's just less going on to complicate the proof. Once you start introducing state, manual memory management, unrestricted recursion, pointers, undefined behaviour etc. it becomes much, much harder to write proofs about programs and justify why they're bug free. This also carries across to humans...it's much easier to reason in your own head why a program is correct when the program behaviour is simple.