TL;DR Haskell made more sense for us to scale with the number of requests (existing FB infra) as well as the number of engineers working on the project (type checking, etc).
What (s)he means though is in Java if firstName is there then it will be a string.
In Clojure firstName might be anything, a string, a number or even an entire other hashmap or type, literally anything. This might or might not cause a runtime crash if you are doing something that assumes it's a string. So you check.
And "saves" is a bit of a misnomer, since it implies the "cost" (of all the static type machinery) is less. Well, dynamic fans (or those with dynamic preferences if "fan" is too strong) will disagree. ;) In practice many systems get streams of bits from somewhere (like the network) that commonly get interpreted into strings and from there other types. The validation and conversion is necessary in any language, after that though it's just FUD to bring up that a function expecting a person with a :name key and string value potentially could be given something else. In the cases where through changes we make it something else, static types are a nice extra assurance on consistency, but that isn't the only way or the most impactful way to gain assurances.
Also this quote was about the cited reason for FB preferring Haskell to Clojure generally, not about this project specifically. IME it's common in big organisations to prefer stuff that has controls at the cost of productivity. It's probably harder to ship buggy Haskell code even if it's harder to write.
TL;DR Haskell made more sense for us to scale with the number of requests (existing FB infra) as well as the number of engineers working on the project (type checking, etc).