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?