When you start to bump into any of these concerns, I'd recommending extracting the functions themselves, rather than breaking the pipeline... which was not something mentioned or explored.

I disagree with this article for the same reasons as everyone else.

I'll also add it's possible to add comments between each line of the pipeline.

I aslo use promise chaining as pipeline pattern for non-chainable calls, as described here : https://blog.kaki87.net/promise-based-pipe-in-js/

Only tangentially related, but I dislike that filter and map are eager in JS. Meaning if you chain them, you allocate N-1 arrays that are being discarded right away. C#, Java and Rust have the right approach.

Ugh, I absolutely hate reading code with a ton of variables that are only used once, because each introduction of a variable is a new thing that I have to first parse and then track to figure out what it does. I would much rather read a pipeline that expresses what is going on concisely without introducing extraneous elements. In particular, I thought that the pipeline at the start of the article was perfectly clear and did not need any of the subsequent modifications.

I think using a better variable name for the "pipeline" result is a much better approach

In array languages (APL -- the Dyalog variant -- not classic APL/2, BQN, J, ...) there's been a trend towards 'tacit' aka 'point-free' syntax, where many ops are combined/composed to avoid the need for named variables.

Unpopular opinion time: I don't like it. As this article says, it's fine for short, simple chains but becomes inscrutable if overused.

This should have never been done in the first place.