Ну, я не говорил о равенстве математики и программирования. Я оспаривал противопоставление, которое сделал Влад. Статью не читал, поэтому ничего не скажу.

> Например, в твоем примере incAll содержит в себе неявный case-analysis
Это зависит от реализации комбинатора. А то получается, что мы сравниваем вызов, использующий комбинатор, и явный инлайн этого комбинатора в реализацию и говорим, что вызов содержит в себе неявный инлайн :-)

Что касается того, что функцию надо переписывать - да, такое встречается. pointfree страшен, лямбда туманнее вызова, а вложенная функция требует придумать ей имя. Выбираем то, что удобнее в данной ситуации.

Я стараюсь как можно дольше не ломать цепочку, но это вопрос предпочтений. А вот то, что в библиотеке над каким-нибудь типом надо построить универсальные комбинаторы плюс описать часто используемые конкретные, мне кажется уже гораздо более важным.

> при его применении мне не хватает ключевых слов then и else, вот такая мелочь, а неприятно.
Ну, Haskell позволяет же строить DSEL, надо этим пользоваться

{-# LANGUAGE EmptyDataDecls #-}

data ThenM
thenM = undefined

data ElseM
elseM = undefined

ifM cond _ t _ e = cond >>= \x -> if x then t else e

> ifM (return True) thenM (print "yes") elseM (print "no")

или, если скобки не нравятся

ifM = id

thenM c t = c >>= \b -> return (b,t)

elseM ct e = ct >>= \(c,t) -> if c then t else e

> ifM (return True) `thenM` print "yes" `elseM` print "no"

Тут можно кучу всего придумать.

Насчёт unfoldr согласен. Бывает, что пользоваться комбинатором неудобно, но это проблема комбинатора, а не подхода, мне кажется. Хотя тут надо думать.