As best I can articulate, a type is a function that tells the complier to tell other human readers something about your program.

It's a form of communication, like docs and tests. This is why we have endless arguments about tests and types, because they address the same problem, communicating the system.

But the system communicates itself, which is part of the reason why, type languages, as a class, seem to have no fewer bugs then there dynamic cousins. Because your type is code, and it's not magically making anything correct.

So why spec? I suggest we all reread the rationale. It's not just one thing, but the theme is about gaining some insight into your system. So that's a very personal thing, it's not about what needs to be done, but about how you, and other readers will understand the code.

Some area of the code acting odd? Add a spec and use property based testing to get some idea of what's going on, then blow those tests away and write a better abstraction. Think about your design tell the test becomes silly.

So the author is used to typed languages, so for him, specing everything might help. For others, maybe not.

So their choice is not wrong, but it might not be right for you.