First, as several people have already mentioned, types, and in particular type-directed programming. In Haskell, I often find the type of a function to be some of the best documentation for it, and I write the type of a function first to describe what I need to write. Partly that's a property of having a strong type system, and partly it's a product of the Haskell culture to want to pack as much semantic content into the type system as possible to help ensure correctness. It's shocking how often you're done the moment you get a new addition to the program to compile and typecheck; it's also shocking how painful it is to go back to C or a dynamically typed language once you're used to that level of static typechecking.
Second, expressivity and modularity. I find that Haskell programs tend to have two types of functions: very short functions (a few lines long at most) implementing the logic of one particular operation (heavily composed of other such functions), and long but extremely simple functions expressing high-level program flow. Good Haskell style encourages writing functions with the most general type they can work with, which results in many functions becoming very general, reusable helpers. As a result, I rarely find myself staring at a half-dozen functions at once trying to figure out what one does and how logic and state get threaded through all of them; each individual piece makes sense in isolation. That's also quite nice when trying to refactor a function.
Second, expressivity and modularity. I find that Haskell programs tend to have two types of functions: very short functions (a few lines long at most) implementing the logic of one particular operation (heavily composed of other such functions), and long but extremely simple functions expressing high-level program flow. Good Haskell style encourages writing functions with the most general type they can work with, which results in many functions becoming very general, reusable helpers. As a result, I rarely find myself staring at a half-dozen functions at once trying to figure out what one does and how logic and state get threaded through all of them; each individual piece makes sense in isolation. That's also quite nice when trying to refactor a function.