It's no less legible than original code and at least expresses the intent of what's being processed, what are the processing steps and what are processing parameters.

a(b(),c(),d(e(),f(g()))) is just function call soup.

And I’d be angry if I saw that too. Break out the soup into variables and have it all be In a clean layout

Use a functional language if you want to chain 10 functions together! I would definitely tell them in the PR to stop being clever and rewrite it

At least I can instantly tell which call is ultimately returning something, in that version.

There's nothing preventing you from not using the pipe for last call or even introducing that rule in your team if you can convince your colleagues it's a good idea or even automate it with the use of a linter.

If it's really good rule you can advocate for it at this stage. It might be prudent to use |> % only inside function call parameter or possibly as right hand of an assignment instead of everywhere where parser expects an expression.

a(b(),c(), g() |> f(%) |> d(e(), %))

Although I'll be honest, I don't like it. Other parameters of a() call for me occlude the flow and the intent.

We could make it a bit better with newlines.

    a(b(),c(), 
        g() |> f(%) |> d(e(), %))
    )

But if a() takes more parameters after the main one then we have the same problem as usual where parts of the same call can end up far away from one another.

    a(b(),c(), 
        g() |> f(%) |> d(e(), %))
    x(), y(), z())

For me

    g() |> f(%) |> d(e(), %))
    |> a(b(), c(), %, x(), y(), z());

is still better and I wouldn't want it to be prevented by language syntax.

That's almost worse. I think I'd have to break out pen and paper to figure out which of those things end up returning arguments to function "a".

I agree that such restriction would make it worse.