Its not that it’s a difficult concept, and its definitely very useful, my issue with is that the way it gets brought up as a Very Important functional concept. It’s an abstraction with a tendency to obscure meaning, the way it’s described is often as a neat trick.
The core reason to use currying is to allow for function composition; if all functions only ever have one argument, it’s easier to glue them together.
What JS does really well is first-class functions - it’s really easy to pass functions around in exactly the same way as values, which is a common thing in functional languages (as an aside, that then leads to implementing simple currying being really easy).
Closures are used heavily JS, and they are what allows a very fluid functional style; + they allow functions to take the place o[and act as a much more lightweight version] of classes in OO languages.
JS is basically a form of the Lisp dialect Scheme, which is generally regarded as having strong functional aspects, and JS can do very nice things in the same functional style, piping data through a series of functions rather than operating on it via classes like OO languages.
What it doesn’t do well is immutability, which is generally useful for a functional language. So you need either rely on convention, which makes the code fragile, or use a library like Immutable.js. But then there is a boundary between code that uses the library and code that doesn’t - same as before, but you just move the fragile code. Redux for example relies on using immutable code, so there’s an issue there.
Elm, Bucklescript, Clojurescript fix that at the cost of needing to compile to JS.