A commentator on my entry on why your main program should be importable mentioned that a third reason is to be able to unit test your program. I agree with the sentiment in general, but in specific I've never been able to get unit testing of my main program code to work very well.

While I can unit test most of the low-level code involved in a program, I've found that much of the high level code, the stuff that goes in the main program, has two issues. First, this code really wants to interact with the real world, unless it is horribly contorted to add yet another level of indirection. (This isn't surprising, as interacting with the real world is really the purpose of the top level of code; everything else manipulates data and objects, and the top level code does something useful with all that work.)

Second, when the program produces output (that should be tested to make sure that it is producing the right output) I find that I fiddle with the output formats a lot in order to get things to look right. Unfortunately this generally destroys unit tests that 'know' what the correct output looks like, and it rapidly becomes too much of a pain to maintain them; instead of being helpful, the unit tests have become an extra bureaucratic step (and obstacle) in tuning the program.

(I am probably unusually picky about how the output of my programs looks, and I also find that I can't tell for sure until I actually run the program and see it live.)