On page 839 of the second edition, Steve McConnell is discussing all the ways that programmers can "conquer complexity" in big programs. His tips culminate with this statement:
"Object-oriented programming provides a level of abstraction that applies to algorithms and data at the same time, a kind of abstraction that functional decomposition alone didn't provide."
Coupled with his conclusion that "reducing complexity is arguably the most important key to being an effective programmer" (same page), this seems to pretty much a challenge to functional programming.
The debate between FP and OO is often framed by FP proponents around the issues of complexity that derives specifically from the challenges of concurrency or parallelization. But concurrency is certainly not the only kind of complexity software programmers need to conquer. Perhaps focusing on reducing one sort of complexity increases it greatly in other dimensions, such that for many cases, the gain is not worth the cost.
If we shifted the terms of the comparison between FP and OO from particular issues like concurrency or reusability to the management of global complexity, how would that debate look?
The contrast I wanted to highlight is that OO seems to encapsulate and abstract away from the complexity of both data and algorithms, whereas functional programming seems encourage leaving the implementation details of data structures more "exposed" throughout the program.
See, e.g., Stuart Halloway (a Clojure FP proponent) here saying that "the over-specification of data types" is "negative consequence of idiomatic OO style" and favoring conceptualizing an AddressBook as a simple vector or map instead of a richer OO object with additional (non-vectorish & non-maplike) properties and methods. (Also, OO and Domain-Driven Design proponents may say that exposing an AddressBook as a vector or map overexposes the encapsulated data to methods that are irrelevant or even dangerous from the standpoint of the domain).