I would suggest still losing it. If you later decide you want the tie in certain submodules, consider the following trick:

package A;

sub new {
  my $proto = shift;
  my $class = ref($proto) || $proto;
  my $obj;
  %$obj = @_;
  return bless ($obj, $class);
}

sub TrialMethod {
  print "The method was called\n";
}

package A::SubClass;
@ISA = A;

sub new {
  my $proto = shift;
  my $obj = $proto->SUPER::new(@_);
  tie (%$obj, 'Some::Tie::Class', $obj);
  return $obj;
}

package Some::Tie::Class;

sub FETCH {
  print "A fetch happened\n";
}

sub TIEHASH {
  my $class = shift;
  my %hash = %{ shift() };
  return bless \%hash, $class;
}

package main;

my $thing = new A::SubClass(qw(hello world));
$thing->TrialMethod();
$thing->{foo};
[download]

See? The example is useless, but it shows that without taking the hit of assuming a tie implementation in your base class you have in no way affected your ability to create subclasses that can take advantage of a tie. You are already this polymorphic. Why force the speed hit?

In fact the generic approach is more polymorphic than the tie implementation you are doing. Why? Because you moved key initializations into TIEHASH, so anyone who wants to override your tie with an interesting implementation needs to couple their TIEHASH more tightly with yours than they should need to.

In fact this is a basic principle of OO design which is good to know. The point of OO is to provide encapsulated behaviour, aspects of which are easy to override. Therefore in your design do as little as you need to with as clean an interface as you can come up with, and plan on using the ease of overriding to later add on any features that could come in handy. Then anyone who doesn't use the flexibility, doesn't pay. But the potential is still intact.