To me, the really important idea wasn't a criticism of static types in general.
Instead it was the idea that static typing in most (all?) mainstream implementations conflates concepts that should be separate, specifically the shape of the information that we have (e.g. what fields of what types), and whether a particular bit of information is available and required (e.g. nullability).
He contends that the former belongs in our usual "type definition", whereas the latter relates instead to a given context. For example, my PassportForm type always has a date-of-birth field in its _shape_, but whether it's statically required/present to exist depends on whether we're at a HTTP API boundary, an internal domain function boundary, writing into a database.
It sounded like that kind of "nullability masking" was intended as a feature of Spec, but I don't get the impression it was ever implemented.
Both ways to parse it are grammatically sound:
(Fruit) (flies) (like a banana)
(Fruit flies) (like) (a banana)
To decide which meaning was likely intended, the listener needs to make a value judgement about the speaker, based on detailed knowledge of the everyday world.
Well played.
Nothing special about the 20% proportion, just that it's proportional to a number which results in perverse incentives.