The best solution is the one that's the most readable and the easiest for other people to understand. That might not always be the same way.

By taking out all the complexity, you take away most of the information we'd need to judge a solution.

The way that you write these things tells other programmers a bit about what you were thinking. Code exists for one human to tell another human something. Although the humans might interpret your intent incorrectly (you can argue elsewhere who's dumber: the compiler or the person), here's what I see in your code:

The first style says that the first branch will probably execute more frequently, but either branch is equally expected (more or less). Compare that below with what I see in the last example.

sub sg {
  if (COND) {
    return 1;
  } else {
    return 2;
  }
}
[download]

Your second example says that you're very cautious because you don't trust what you see. You should never reach that die statement, but you think that you might so you put it there to catch bugs. You probably don't care out coverage testing too much when you purposedly add unreachable code.

sub sg {
  if (COND) {
    return 1;
  } else {
    return 2;
  }
  die "should never reach this";
}
[download]

The last one says that normally this subroutine returns a certain value (computed, from a variable, whatever), but in some special cases you want to short-circuit all the processing and return a different value. Most of the time, however, you expect the full subroutine to execute.

sub sg {
  if (COND) {
    return 1;
  }
  return 2;
}
[download]