Since "breaking code" is super subjective, and generally speaking, trying to "cover everything" is a recipe for hell.
Anyone able to expand on what the author meant by this?
What I had in mind specifically in the answer, was the case of changing "interfaces" between parts of code. For example, the case of changing a function's arguments, or how it uses them, but omitting to change a call site. Checking that the call site just calls the function would not be enough to produce a failing test, especially without type safety. The test would actually need to assert on what the function does, e.g. its return value for a pure function.
Yes, I think trying to test against every single possible breaking change is not valuable.
Basically, you put the customer first. Make sure your features are tested such that they can't fail without a failing test before writing lower-level tests.
This is also the approach advocated by the popular book Growing Object-Oriented Software Guided by Tests.
Here is where testing becomes very helpful.
Only to the extent that your spec is incomplete.