I'll take a guess that something like pure functions lend themselves to formal, concise specs. Pure functions are, in the end, just input and output, not something complex like a program that outputs some complex bitmap every 30 milliseconds. Haskell has found pure functions to be very practical to have as 'distinguished citizens'; there are enough problems which can to a great degree be expressed with pure code.
Someone might say "but Haskell itself doesn't solve practical programming problems", or whatever. The point isn't Haskell or pure functional programming per se; it's just an example of things that easily lend themselves to formal specs. Whether more complicated, perhaps effectful programs lend themselves to formal specs (I think ATS might be able to express such specifications) is more hard to answer.
HN was written in a language where functional style is the norm, and yet HN couldn't have been designed via spec. I say this as someone who has thoroughly studied HN's codebase. If you spend time examining it, it becomes evident that most of the features were extemporaneous. There is little which was thought out in advance. The recipe for HN was: do the most important thing each day; repeat for 2000 days. Such a recipe is fundamentally anti-spec, because by day 5 your spec is outdated.
Spec xor exploratory programming. The codebase is the spec.
Someone might say "but Haskell itself doesn't solve practical programming problems", or whatever. The point isn't Haskell or pure functional programming per se; it's just an example of things that easily lend themselves to formal specs. Whether more complicated, perhaps effectful programs lend themselves to formal specs (I think ATS might be able to express such specifications) is more hard to answer.