I don't have the energy to write a real example to show you what I mean, but I can point at a case which would have been helped by it. Download Pod::Parser and in it look for the implementation of parse_paragraph. There are a lot of optional hooks provided, and the way it was done is to pass all of the data through a series of functions then keep on checking flags. But most of the time those functions (like preprocess_line and preprocess_paragraph) don't do anything.

I once looked at it closely, and couldn't tie out the current API. But if you had an API where you created all of the hooks you wanted then asked it to build a parser, it could then create a function, and then once (and once only) decide to only include lines with optional hooks if you were using it. The result would do the same task several times faster since optional hooks would not be present in the final output. (Without having looked I would suspect that Parse::RecDescent does this.)

As for why the eval, to do what I describe you would want to build up the string, as you walk through checking once for the hook then including or not including bits of what could be part of your sub, then call eval to have it return the final subroutine for you.