Maybe you want to have different implementations or want to replace some parts, while still having a defined sequence of calls.

Personally, I've always run up to the limits of such frameworks, but I can well imagine an ETL task that is basically:

package ETL::Import;

sub run( $class, $input_file, $table ) {
    my $payload = $class->convert_to_csv( $input_file );
    $class->cleanup( $payload );
    $class->load( $payload, $input_file, $table );
    $class->verify( $payload, $table );
};
[download]

... and then having

package ETL::Import::CSV;

...

package ETL::Import::Fixed;

...
[download]

... where each class only overrides (say) ->convert_to_csv and/or ->cleanup.

As I said, I've almost always wanted to change just a tiny bit in the sequence of the call order, or maintain just one bit more information, so I prefer to have the logic of ->run in the main program instead of having it in some superclass. But if ->run is the result of a refactoring where it has proven flexible enough already, I can see how that could work out.