> any example where functions are dyamically composed as a pipeline needs TCO to avoid leaking stack

Sure, but in the rare case that this is a problem, you can trivially workaround it:

    (reduce (fn [acc f] (f acc)) init [f1 f2 f3])

This approach may not match the Haskell ideal of FP, but it's actually got many significant advantages. Frequently, programming with data structures is _better_ than programming with function composition. For example, you may choose to do something like this:

    (reduce (fn [acc f] (println "executing" f) (f acc)) init [#'f1 #'f2 #'f3])

Where this is now a pipeline with logging of the stages. You can't do that if you prematurely select function composition as your primary way to structure computations.

The Haskell research community is in the process of undoing this brain damage on the monad front by embracing extensible effects, free(-er) monads, "reflection without remorse", effect interpreters, etc.

Once you need any sort of symbolic reasoning, you drop opaque composition and work with data. This is true in every language, FP or not. People tend to do exactly the right thing already: abandon function combinators and write interpreters over data structures.