Right on: higher-orderness is an excellent abstraction facility.
One nit to pick: I'd even say that absence of side effects matters even
if you don't have lazy evaluation. In a strict language, it helps if the
HOF doesn't have to observe constraints on the order in which some
submitted functions may be called, or how often to call them.
It's even simpler.
For communication between subroutines, it's better to move all
communication channels into the parameters and return values, because it
makes them explicit. Implicit channels are viable only if you have
strong modularization (and OO with implementation inheritance doesn't
offer this because subclasses may decide to play by different rules).
For communication within a subroutine, state isn't a problem. It's
already a general recommendation to use a local variable just for a
single purpose, so people are already working in a functional style
(unless they're programming loops, which can be conveniently wrapped
using HOFs in a functional language).
The trend is towards avoiding program-internal state anyway :-)
The exceptions being:
a) Efficiency (as always), sometimes even with good reason (large
arrays). This is a serious issue, since large arrays aren't going to go
away (array sizes tend to grow with available RAM, and if it's graphics,
there's always a better frame rate to achieve). Various approaches
exist, it's just unclear which of them lends itself to the cleanest
b) Interaction with external state. Several satisfactory approaches
exist (I know about at least two, the IO monad and modal systems), and
it remains to be seen which of them works best in practice.
c) Interaction with C libraries. That's a mess. Well, interfacing with C
is generally a mess, and C libraries tend to have more gratuitous state
than anything else. There's a *large* conceptual gap between most C
libraries and the stateless world. My expectation is that FPLs are
"ready for the masses" as soon as they have a critical mass of
libraries, many of them "functionalized" interfaces to classical C APIs,
others complete rewrites. (This could be furthered if an FPL can
generate libraries with an easy-to-use C interface. I think such
libraries would make far better showcases for FPL ideas than anything else.)