By limiting the damage a single crappy programmer can do.

Everywhere people talk about 'large' teams maintaining a large codebase in this thread, substitute 'mediocre' teams stuck with a poor bloated codebase that is the vehicle for their ambitions. It's just not worth anybody's time to understand its unique needs in detail, especially since any improvement you make today risks being messed up tomorrow.

I can understand using static typing if you already have a large codebase that's statically typed, but is there any reason you'd start a project with a statically typed language?

Yeah the benefits of static typing are front-loaded at the start of a project. I might rewrite in a statically-typed language for performance if it ever needs it, but I wouldn't start statically-typed.

My lisp interpreter above allows me to tear out a lisp function and replace it with a C function, while leaving the unit tests untouched.

Crappy developers for one.

Most enterprise projects with modules developed in offshore, suffer from crappy developers that barely know one single programming language.

Forcing them to write lots of unit tests as required by dynamic languages development leads to nothing.

The only way to minimize broken systems is to use languages that force them to stay on course.