Look up something called currying. It solves the issue. You can still write functions with multiple arguments and then "curry" them into functions of just one argument.
Of course this does not solve the readability issue.
Yeah technically it's not point free. But technically nothing can truly be point free just like nothing can ever be truly purely functional.
In purely functional programming your IO and state has to live somewhere just like how your points in point free programming still have to exist on the function call.
A function that takes multiple arguments introduces extra points to your program similar to introducing extra IO calls to your purely functional program. These points are inevitable additions to your program. The philosophy remains point free however.
Another way to think about it is that every parameter in a point free program is tied to a point somewhere up the pipeline. If you introduce a function with multiple arguments, that extra argument will still need to be tied to a point either right now or up some other pipeline.
So either you curry in a point into that extra parameter or you curry in the result of another pipeline.
A good way to think of the point free style is a series of pipes flowing in one direction, from left to right. All pipes segments must be eventually connected to a source and eventually flow to an output.
A function with 2 parameters is a T junction within this system with 2 inflows and one outflow. No matter how you configure your network of pipes; points need to live to the at the source and output of this network either as IO or actual state. There is no "point" in creating a network of pipes that isn't connected to a source and an output.
When you introduce a new T junction into this network of pipes, you will inevitably need to connect these inflows to points at the source of the pipe network. There's no way around it.
Don't get me wrong, I rather agree with you on the conceptual side of things; I just wish there was a pretty syntax to do it practically.
As you mention them, pipes, for instance, get close to that, and e.g. Elixir uses them to a great result. However, it requires unambiguous priority of the arguments and cooperation & discipline from the librairies authors, so that piping follow the intuitive (and hopefully unambiguous) understanding of the data flow.
I wasn't talking about Unix pipes. Apologies. I meant actual pipes. Like sewage piping.
Reread my pipe example but imagine a 2D diagram of physical pipes instead. This is the physical analog of the point free style and the origin of the term when used in unix. The diagram should get around the problem that is caused by the point free style (aka Unix piping) when you use text to represent the concept. In fact this is one of the few times where graphical representations of programming is clearly superior to text.
Of course this does not solve the readability issue.