Isn't all that mandatory as soon as you have high order functions (which can return functions) and type abstraction (where you can hide functions behind abstract types), regardless of easy access to partial application and/or currified functions?
The question is about unary vs n-ary functions. If you have n-ary functions, this information is given by the type signature, you don't have to break abstraction access it, so it works as well in higher-order functions and is not affected by abstract types (in this context, a binary function is not an unary function).
In any cases, the performance cost is not that big (and doesn't come up in regular OCaml programming) and it's a bit late to worry about the implementation complexity cost now that everyone uses those features. The discussion is interesting for new languages, but that's not the case here. Implying those costs are a good argument for syntax changes is a bit misleading.
OCaml is in local optimum: it has to deal with that, and it does it quite well. This it not going to change.
But the language we are talking about is not OCaml. In Reason thread, I started the confusion by giving some possible semantics arguments to the syntax changes, even though I noted that these arguments don't apply in Reason case because we cannot change the underlying semantics.
The point was just to show that there is more than syntax in this application story and that OCaml veterans opinions are not clearly in favor of unary functions, for reasons which are not immediately obvious.
My personal worry is that it makes some classes of libraries very painful to use. Notably combinator-based libraries, which are quite common in the OCaml ecosystem (cmdliner, fmt, angstrom, ...).
That claim is not supported. For average code (not combinator heavy), feedbacks have been largely positive, and we didn't try anything with combinator heavy code. This is something that should be done but I would refrain from drawing conclusions too early.