Err.. sorry for the long comment, I meant to just add my simple thoughts and then got a little side-tracked.. I hope this makes sense!
Well, in addition to the things Eric has explained, my favorite simple reason is: function composition means you don’t have to start over when performing similar logic on multiple types of things. Sure, reusing the original snippet of code with the api chaining would be easy. You could just wrap it in a function. This seems similar when we’re looking at a single example with function composition. Things start to favor function composition as soon as you re-use any of that part of the logic that was used for that first function. Instead of building your subsequent functions from the ground up with the api.chaining method, you can re-use the components of the function composition method to compose new functions.
Function composition is the same reason components/modules and DRY is good: reusing things. You can create a ton of small functions that work on certain types(objects/arrays/strings…), and then re-use those composed functions to build more complex composed functions. Without function composition, this creates a very fragile codebase. By abstracting away the “boilerplate variables” as Eric called them, you are programming in a more mathematical way that cannot possibly break unless you try to set X to cow when solving for X + 1 = 2.
Also, partial function application becomes much easier with function composition, and partial function application makes things so nice. I wrote a webapp that used partial function application to get a set of data from a server and operate on that data like a stream. I could then save the partially processed data as a variable, and then split that variable into further streams, and I never had to re-request the data from the server.. it was extremely easy to track down bugs and usually, once a bug was fixed, it cascaded through all of my webapp because I was reusing functions that were built on top of simpler functions.