Seconded with the proviso that "aren't many" is not the same as "aren't any".

A quick counter-example is a subroutine that takes a number of options and returns a closure with a large number of optional hooks. In this case it can be very nice to have the closure be the result of an eval, with the text of the subroutine being assembled from just the hooks you use. In other words move the cost of the hooks to tests when you compile the closure, and not pay every time you call the closure. (As I pointed out to the author, if Pod::Parser had a slightly different interface it would be an excellent candidate for getting a massive performance boost from this trick.)