The question of how to Design things or how to abstract things in programming is thus in essence a discussion about different ways of composing things (aka different ways of abstracting things). It is the drive behind all the arguments behind different programming styles, different programming languages and different system designs.
The way you compose primitives in functional programming is through function composition. The debate between functional programming and procedural programming and OOP from a "design" perspective is thus the debate between which primitive composes better:
The function or the procedure or the object?
It's a question of Design and at the heart of it lies composition.
I think most people who love functional programming know on some level that the "design" of functional programs "feels" better. Most of them have never thought about "why" this is the case. They have never tried to answer the question of what is the true nature "design" from a programming language perspective. What is this vague thing we are optimizing for? We are constantly inventing new programming languages/patterns in attempt to answer the question and instead much of the time we move in a flat circle and come back to where we were before (see golang).
I believe FP moves the ball forward in terms of design. The thing is, most people can't see why. They rely on inexact feelings, and a lot of the times they even feel the opposite. I've heard people talk about FP is just a fad similar to design patterns and OOP. Without the ability to develop an exact concrete answer why one "design" is better than the other, we will always move in circles even when we discover a "design" that is actually better.
If you want an exact, concrete answer to the question of "design" the answer lies in the mechanics of composition.