Compiled languages prunes down the number of combinations of errors you need to test for in a way that doesn't happen for a truly interpreted language.

Real programs aren't written fully and then tested fully.

They are incremental pieces of work.

With a compiled language, you can focus on what to test based on what additions you have made.

With interpreted languages, you have a much harder time to figure out how the changes may break older, pre-tested code.

It is a well-known fact that functions can normally be subjected to full testing whenever they are modified. You can have a test harness that tests all if statements, all limits for all variables etc. When combinting 500 functions into a complete program, the combinatorial math tells us that we can not perform such a complete test. It could take billions of years.

So we have to settle for testing what is possible to test. And the compiler (or static analyzers like lint) will be part of that testing environment. And they will test huge amounts of combinations that you will not be able to test with the interpreted language.

The compiler might drop the number of needed tests from 2^20 to 2^10. But that means that it will catch a large number of errors that you just can not set up test cases to catch for the interpreted language. You wouldn't even have the thousand years it would take just to write the test cases.

Remember also that most interpreted languages have weak type handling. So they can have a string "15" and allow that to be multipled by 2 and end up with the result 30. Weak type checking sometimes helps. But sometimes, it makes the program create a result even when the code was wrong and we sent the wrong variable to the function. With weak type checking, you get into troubles like is "" same as NULL or the value zero? Is "15hello" the number 15 or invalid? Should "hello " + "world" concatenate two strings or be a failed attempt to add two numbers from text input boxes on a web form?

But there are many other things that can go wrong with an interpreted language. For example the upload of a PHP-based web application to a server accidentally make one of the source files not readable by the web server. The application can run fine for a long time, until a web visitor does something that requires this file to be included for parsing.

Interpreted languages that gets bad data from a text input and doesn't guard about it, could accidentally try to run the text input data as if it was code. A common example is SQL injection, where people enter text data that looks like the end of a text string, and then follows this with a semicolon and some dangerous SQL statement. The programmer thought he performed a single SQL query in the database, but his query ended early and after that followed a SQL statement requesting the database to be dropped (i.e. thrown away).