Well, I'll have to think about a more elegant and efficient way, but so far I don't see any serious problem with what you are doing. Remember the saying "a sufficiently encapsulated hack is no longer a hack." The questions to ask are: "is this really causing efficiency problems?" and "is there a more maintainable solution?" If it suits your needs, don't fix it without good reason. This is a Bad Idea.

Elaborating: let's say you make this method 50% more efficient in terms of "time" (loosely speaking). If you find out that it's only taking up 1% of your programs runtime, you possibly have wasted time making a non-issue more performant. Further, I find for myself that when I start worrying about performance issues, even on systems I've built from the ground up, I almost always guess wrong about where the performance bottlenecks are (even the "obvious" database performance issues may be memory bound, IO bound or just bloody awful queries).

That being said, I would personally create a private $can_contain method.

my $can_contain = sub {
    my ( $self, $object ) = @_;
    $self->container_type eq $object->container;
};

sub insert {
    my ( $self, $object ) = @_;
    unless ( $self->$can_contain( $object ) ) {
        die "I can't hold that object!";
    }
    push @{$self}, $object;
}
[download]

With private methods like that, you can be guaranteed that no on else will inherit them, no one outside of your class will see the data they don't need to see and if anything else in the method needs to know if it "can contain" something, you're safe.

Though I still wouldn't fix it until it merits the fix :)