TL;DR: No

IMO Your question contains a bad assumption.

Bad assumption

there's nothing wrong with using a feature in moderation

This is the wrong way to look at a language and it's capabilities. You should use whatever idiom, feature, etc, yields the shortest, most maintainable implementation that has reasonable performance for you/your team. It should not be driven by how many times you've used it so far. Programming decisions shouldn't be governed by an arbitrary limitation on the number of time you can use a particular construct on the belief that "this amount is okay, but one more is too much".

The Question

The question is "is currying to complex for you/your team?". There are certainly many people for whom currying is not complicated and use it all the time. You mentioned you just learned it, so it is a valid question to ask yourself. However, and this is the important bit, this is a question you must answer. You should consider any external factors like deadlines, the cost of making mistakes (which will rise anytime you're using something unfamiliar), etc and weigh that against the benefits.

Complexity

Complexity is largely a function of familiarity. Familiarity drives understanding. When you are familiar with and idiom it isn't any more or less complex than anything else. Think about the notion of anonymous function, objects and types, and how complex they were when you first came across them. Conversely, if you never gain any familiarity with the idiom, it is and will always remain complex.

Average Team Skill Level

The question of not using because most of the team doesn't understand the concept is something I have considered in the past. However I have always decided I would rather force people to learn and develop, rather than have everyone program to a "lower" common denominator. In the past I have had to compromise the best implementation I could give for fear someone else will not be able to maintain/understand it. Now that I can set policy this doesn't happen.

TL;DR: No

IMO Your question contains a bad assumption.

Bad assumption

there's nothing wrong with using a feature in moderation

This is the wrong way to look at a language and it's capabilities. You should use whatever idiom, feature, etc, yields the shortest, most maintainable implementation that has reasonable performance for you/your team. It should not be driven by how many times you've used it so far. Programming decisions shouldn't be governed by an arbitrary limitation on the number of time you can use a particular construct on the belief that "this amount is okay, but one more is too much".

The Question

The question is "is currying to complex for you/your team?". There are certainly many people for whom currying is not complicated and use it all the time. You mentioned you just learned it, so it is a valid question to ask yourself. However, and this is the important bit, this is a question you must answer. You should consider any external factors like deadlines, the cost of making mistakes (which will rise anytime you're using something unfamiliar), etc and weigh that against the benefits.

Complexity

Complexity is largely a function of familiarity. Familiarity drives understanding. When you are familiar with an concept it isn't any more or less complex than anything else. Think about the notion of anonymous function, objects and types, and how complex they were when you first came across them. Conversely, if you never gain any familiarity with the concept, it is and will always remain complex.

Average Team Skill Level

The question of not using something because most of the team doesn't understand the concept is something I have considered in the past. However I have always decided I would rather force people to learn and develop, rather than have everyone program to a "lower" common denominator. In the past I have had to compromise the best implementation I could give for fear someone else will not be able to maintain/understand it. Now that I can set policy this doesn't happen.