for me the #1 benefit is first-class functions. once you have that, you have the best that functional programming has to offer

more generally, the composability of functions allows for more tacit programming. for example:

  array = [ 1, 2, 3 ]

  sort( array )

  print( array )

here sort is a function that takes an array and sorts it in-place. the sort function itself doesn't return anything. but if we have it return the array, we can write the above this way:

  print( sort( [ 1, 2, 3 ] ) )

not only does it read easier, you also no longer have to think about the state of the array

from there you can enforce immutability, and then you have to worry even less about the state... because there isn't any

but to me that's extreme. the ideal of FP is nice, but taking something fundamentally dynamic like an algorithm or a working software system, and then trying to process it with something that can in its nicest terms be called anally rigid, is IMO fundamentally misguided. the only language in which i've seen this work is XSLT (a strict functional language,) because in its case you're dealing with rigid things to begin with (declarative XML documents) and on top of that it maps perfectly to its domain (XML documents are structured/"composed")

of course, strict FP has lots of benefits for the computer regarding optimization. but from a language design POV i'd rather give full power to the programmer and do my best to optimize later (eg via JIT)

so, IMO, use first-class functions all over the place and take advantage of the conceptual alleviation that composabilility offers, but consider the type-anal, FP-anal, OO-anal, and pretty much anything-anal languages to have been designed by crazy kooks who can't see the very wide line between theory and practice