In the fast majority of the code I write, I use plain old die, without wrapping them in eval. But this has more to do with the kind of programs I write than with a deeper philosophy. Most programs I write run quickly and are of the form "here's a bunch of things (files, arguments, environment variables, URLs), produce something". And the something can either be produced, or it can't. So, if there's something missing, or wrong, about the 'bunch of things', nothing should be produced, and the program should terminate with an error message. Which is exactly what die does.

Programs performing database modifications do use another technique though. There I will do things like:

    eval {
         start transaction or die;
         ...
         prepare or die;
         ...
         execute or die;
         ...
         fetch or die;
         ...
     };
     if ($@) {
         rollback;
         die $@;
     }
     else {
         commit;
     }
[download]

If something goes, I die as usual, but this die will be caught, the transaction will be rolled back, and we cascade the die upwards (where it's most likely not caught again).

Abigail