> It doesn't matter if your functions are pure if they return a unique data type for your API or library that is not understood easily by the caller.
If it's an abstract data type, it doesn't have to be understood by the caller, it just has to be passed to another "lego brick" which understands the abstract interface. If it's a structured data-type, then there's no reason why it shouldn't be understood by the caller, the type should tell you how to consume it. I do not understand your point.
> So the solution is to make that data easily convertible or generic.. and guess what? That's no different than doing the same in an OO language
I guess you mean structured data types here? But you have missed my point completely about side-effects, it is side-effects (coupling via back-channels) that prevent composition, in general, in an OO language. OO languages also typically have an obsession with nominal types that can impede reuse.
> The key ingredient in making software reusable and portable is the talent and experience of the engineer, regardless of language.
You appear to be suggesting that languages/tools don't matter? Why not aspire towards languages that encourage safe composition and re-usable software? Your argument reduces down to "good motorcyclists don't need helmets".