[nextaccountic]

Note, mainstream programming already has widespread use of a bunch of recursion schemes, like map, filter, and fold (also called reduce). It's generally accepted that using map and filter leads to code much easier to understand and modify. Fold is a tiny bit more complicated but generally speaking it is worth it, but there is still some room for specialized folds like a "sum" operation to make code simpler. (map and filter are also special cases of folds, but that's not an interesting observation)

What's missing from this picture is that recursion schemes are not only useful for lists and other sequential things like arrays, vecs, iterators etc, but also for trees and other data types with richer structure. There's some types implementing map here and there (like Rust's Option, which implements map and filter as if it were a list containing 0 or 1 element), but the generic abstraction of "types that have a map operation" for example (the thing Haskell calls Functor) would be really useful to enter mainstream programming some day.

Now, about the more complex recursion schemes: many have too much cognitive weight to be useful. So often a direct recursion will be simpler and easier to understand. But sure, it would be cool if people were more familiar with things like hylomorphisms and such (even if by other name - folds may also be called catamorphisms but nobody calls them that)

I think that the "overton window" of programming constructs is slowly but surely moving towards the more theoretical aspects of functional programming though. So maybe in some decades this stuff will be so familiar that using them won't make code hard to follow.