First, and most important, it requires a programmer to make a design-time decision to support currying. Currying hits its stride only when it is pervasive, and I don't want to limit its use to the functions that have been made "curry ready" ahead of time by having been anointed with the right prototypes of annotations.
I agree somewhat with this point. I think that pervasive currying (as you put it) is very useful only in some cases, but can wreak uncontrolled havoc in others (okay maybe not that bad). For instance, your technique would not work with OO, since the $self value cannot be known when you curry your function. And while most people don't think of currying and OO as going together, nothing could be further from the truth. IMO it can be used a very clean type of closure where the $self instance can not only carry data, but behavior as well. I use this technique myself.
I also take issue with the idea that there is something wrong with design-time descisions to support currying. Sure, in some cases you will want to curry a non-designed-for-currying function, but a designed-for-currying-function has the potential to be far superior. I would even argue (somewhat weakly) that a good functional programmer always designs for currying.