[Vinnl]

While I agree that that's the case for the promises in many such tutorials, I think this article explicitly shows that that isn't inherent to the thing that FP is about.

Your quote is specifically about the code formatted in such a way, with arrows drawn all over it, to match the box diagram. But if you look at the code as it would actually be written, in a functional style:

        def make_tiramisu(eggs, sugar1, wine, cheese, cream, fingers, espresso, sugar2, cocoa):
            beat_eggs = beat(eggs)
            mixture = beat(beat_eggs, sugar1, wine)
            whisked = whisk(mixture)
            beat_cheese = beat(cheese)
            cheese_mixture = beat(whisked, beat_cheese)
            whipped_cream = whip(cream)
            folded_mixture = fold(cheese_mixture, whipped_cream)
            sweet_espresso = dissolve(sugar2, espresso)
            wet_fingers = soak2seconds(fingers, sweet_espresso)
            assembled = assemble(folded_mixture, wet_fingers)
            complete = sift(assembled, cocoa)
            ready_tiramisu = refrigerate(complete)
            return ready_tiramisu

...then surely you would agree that that doesn't look like a mess at all, compared to the imperative version a couple of lines below it? And yet, it brings all the benefits described in the following paragraphs!

[wruza]

There’s nothing particularly FP about it though. A function taking a value and returning a new value is as “FP” as a good deed is “Christian”.

[Vinnl]

That's mostly a discussion about semantics, which isn't that interesting IMO. It demonstrates the use of pure functions that avoid side effects, and argues that this is how you can get some important benefits associated with functional programming without having to "read a multi-faceted inside-out mess".

If you have a definition of FP that intrinsically includes that mess, then sure, maybe that's harmful, but that seems orthogonal to the article in question.