The %plan/phases makes sense, but that's about it. (It'd be fairly easy to retrofit CGI::Application so it uses the same concepts and behaves by default like CGI::Application does now, ie default application loop...).

The so called plugin interface is what makes the least sense. CGI::Application's template stuff was too specific, but yours is not generic enough. loadPlugin/loadPlugins/addService? I think you're going a tad overboard here (too much "architecture" that accomplishes nothing). I would simply look to borrow ideas from (or make use of) Class::Accessor and Class::Delegation to simplify creation of accessors/proxy methods if people want them, and it seem like they do. Something like

package Conan::O'Brien;
use CGI::Simple;
use base qw[ CGI::Pipeline ]; # or whatever

__PACKAGE__->proxyaxx(
    param => 'query',             # $self->param( 'query' );
    proxy => qw[ param ],         # $self->param(1) calls $self->param
+('query')->param(1);
    name  => 'query',             # $self->query() returns $self->para
+m('query')
    addHandler => [ Init, 'method', $stage ], # calls method on query 
+during $stage
);

sub setup {
    my $self = shift;
    $self->param( query => CGI::Simple::->new() ); # so now query/para
+m work
}
[download]

What made the least sense about plugins was the fragmentation of the namespace. CGI::Pipeline and WWW::Pipeline (its not like CGI::Simple and Calendar::Simple are related)? Should've been CGI::Pipeline::Plugin (like Template::Plugin).

And then the "basic services" (header/param) end up in WWW::Pipeline::Services so CGI::Pipieline has nothing to do with CGI anymore.

update: I almost forgot, if you stick with what you currently have, it'd be a good idea to restructure your distribution (you probably would've anyway), so that the tarball expands to something like

CGI-Plugin-0.01/
lib/
lib/CGI
lib/CGI/Plugin.pm
lib/WWW
lib/WWW/Plugin
...
Makefile.PL
README
...
[download]

update: d'oh, i see i keep saying CGI::Pipeline for some reason, lol (late night)