Having curry by default allows you to create very readable code using function composition, which is the primary way of transforming data through multiple steps in FP.

For example of a typical imperative approach to applying functions:

     function price(product) {
          product == 'book' && return 20
          product == 'laptop' && return 10
     }
     function addShipping(product, price) {
          product == 'book' && return price + 10
          product == 'laptop' && return price + 5
     }
     function addTax(price) {
         return price + (x * 0.13)
     }
     function total(product) {
          cost = price(product)
          subtotal = addShipping(product, cost)
          total = addTax(subtotal)
          return total
     }

Compared to a haskell-style JS which combines currying and function composition (. combines functions in Haskell):

     price :: Product -> (Int)
     price p =
          p == 'book' && () => 10
          p == 'laptop' && () => 20

     shipping :: Product -> (Int -> Int)
     shipping p =
          p == 'book' && (x) => x + 10
          p == 'laptop' && (x) => x + 25

     tax :: Int -> Int
     tax x = x + (x * 0.13)

     total :: Product -> Int
     total p = tax . shipping(p) . price(p)

Alternatively, you can easily create object specific total functions:

     totalBook = tax . shipping('book') . price('book')
     totalLaptop =  tax . shipping('laptop') . price('laptop')

Note how in the FP `total` version the data is not held in temporary variables but passed directly to the next function, which could be a performance gain.

Another benefit is how it's easier to work with curried functions when using map/reduce and list comprehensions - two other fundamental building blocks of FP programs. For example, you can pass a curried `shipping` function directly to map whereas `addShipping` would required an anonymous function (since it has two arguments).

      map(shipping('laptop'), [5, 10, 20, 30])
   
      vs

      map(function(price) { 
         addShipping('laptop', price)
      }, [5, 10, 20, 30])

The performance question is largely a question of the implementation and compiler optimizations. But considering we're working in a browser environment the "bottle-neck" is going to be DOM interaction not passing around curried functions everywhere.

Additionally, you are much more like to create functions in FP with single arguments rather than multiple in order for composition to work cleanly.