While I see how the prevalance of assertions can relate to a weaker type system, I am not sure it explains everything. In my experience with Game Development, for instance, which was largely C# and C++, there were quite many situations that an assertion was the best option.

In general terms, a game state can evolve in almost infinitely many ways and most stuff has some degree of dependency on the world and other objects. In this light, there isn't really much you can catch with unit tests, for instance. Most of the real issues arrise from the coupling of many units rather than malfunctioning parts.

On top of that, most of gaming code executes across a non-trivial amount of time. For instance, when jumping, a character will do a pre-animation then jump. This pre-animation can last anywhere from a few frames to a full second. When coding the actual jump, you really can't be sure that all the conditions that were met before the pre-jump still hold. Maybe your character got hit by something or the platform it was standing on no longer exists.

Ideally, the grand scheme of things should manage to never fully complete a jump if it was interrupted. However, your best bet in catching a inconsistent state is to literally check at the beginning of the "post pre-jump" whether all jump pre-conditions still hold.

Long story short, you don't have as much control of the execution to ever be sure you won't run in an inconsistent state (keep in mind that a lot of stuff runs on parallel threads also). Our best bet, most of the time, is to literally assert if things are consistent and, if not, try to backtrack the source.

Plus, you just can't synthetically replicate everything, you really need to have this all setup during all playtest sessions.