Do you have a rationale for drawing the line there? Why don't we go further and claim that (say) FP is also about laziness, if your language does not support first class laziness it's not functional. Or first class continuations, etc
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.
However I think the claim "functional programming is about function composition", together with the claim that "other things commonly associated such as immutability are not defining features of functional programming", is a stronger claim that seems unsubstantiated. There are many design choices analogous to immutability vs mutability that people argue are defining features of or are not defining features of FP. A Lisper might argue that closures over first-class mutable data can be part of the FP paradigm, or even that an FP language must allow that, while a Haskeller might argue that no, this must be modelled on top of immutable data. I see merit in common arguments presented for both viewpoints. A Haskeller might argue that monadic composition and syntactic support for it is a defining feature of FP, because simulating it with only "plain" function composition is deficient in some way. A criticism of this might be that monad transformers don't compose well. They might argue functions that functions should not be strict by default, because non-strict functions compose better than functions which are not. There's a great Quora answer that talks about this (https://www.quora.com/After-Haskell-there-is-no-language-whi...) and I remember a blog post framing this more explicitly in terms of composition that I can't find right now. I'm just sketching arguments that I've heard/thought about, but all these arguments deal with composition, abstraction and functions.
I don't like the framing of "does a procedure or an object compose better" because not all design choices fall into one of those, in fact I think very few do in a useful way. Is multiple dynamic dispatch (e.g. Julia) a way to compose functions or objects?
I never went into why FP is better. I only said I believe it is better and that composition lies at the heart of this differentiation. So you are offering an opinion on something that I haven't expanded upon yet.
Allow me to explain why I believe composition in FP is a "better design" than other paradigms. First let's get on the same page about the true nature of design. What is it? I talk about it here: https://news.ycombinator.com/item?id=21953290
Once we're on the same page on what is design in general you can read about why I believe FP is better in general. I posted on quora, a definition of "good design" in the context programming and program organization. Then I go into why FP under this definition is "better."
https://www.quora.com/Is-senior-full-stack-engineer-Ilya-Suz...
The answer is not straightforward and I get into the caveats in the comments on that quora post.
I believe the definitions for design that I am describing are universal and concretely illustrate what we all talk about when we talk about "design." If you have a different definition of design than the problem is just semantic in nature. At the very least I think we can agree that in terms of this definition of "good design" FP is the better than OOP and imperative.
If you follow the links, read and completely understand what I'm writing you will see I covered everything. Right now it appears you didn't read it.
In the links I provided, I define "design," and I operate within the bounds of that definition so you are clear about what I'm talking about. Please read.
Which one of your links define the terms "FP" and "OOP"?