It's important to be able to delete dead code even if your developers never write any, because earlier compiler optimization passes can create dead code. For example, consider this simple function written in a hypothetical dynamic language:

  function add(a,b) { return a + b }

Our hypothetical compiler turns this function into some IL that looks like this:

  function add1(a,b)
  {
    if(is_null(a)) throw ArgumentNullException()
    if(is_null(b)) throw ArgumentNullException()
    low_level_generic_add(a,b)
  }

...where low_level_generic_add sums a and b if they're integers, or looks for a suitable overloaded operator+ and invokes it if they're not.

Suppose further that our hypothetical language has a tracing JIT, and that most of the time when a and b are called, they're both integers. In that case, the compiler might perform the following transformation:

  function add2(a,b)
  {
    if(is_integer(a) && is_integer(b)) return add_integers(a,b)
    else return add_generic(a,b)
  }

...where add_generic is just a copy of add1 above, and add_integers is a copy of add1 with low_level_generic_add() replaced by the less-expensive perform_integer_addition()

  function add_integers(a,b)
  {
    if(is_null(a)) throw ArgumentNullException()
    if(is_null(b)) throw ArgumentNullException()
    perform_integer_addition(a,b)
  }

But suppose one more thing: let's say integers in this language are value types; that is, that is_null(some_integer) is never true. Then you can get another performance win in add_integers by removing the two null checks - but you can only find out about that if you have a dead code detector.

This has been your woefully incomplete dynamic compilation moment.