One problem with runtime checks is that they of course only work at runtime but you also must manually assert against them. A bulk of your test suite now exists

One problem with runtime checks is that they of course only work at runtime but you also must manually assert against them. A bulk of your test suite now exists just to execute runtime paths through your code to trigger your guards at all. Then your tests often have to duplicate the very assertions that you already specified in your guards. Another problem is that your runtime guards are often ad-hoc and can drift from your data model, turning into debt that you need to manually reevaluate and clean up. In my experience, there's nothing quite so permanent as a defensive nil guard that everyone is too timid to remove. But it's not clear what you mean by "is it enough". I definitely use runtime asserts in dynamically-typed languages like Javascript to try and fail as fast as possible in critical functions.