But what makes you say that this usage is almost always an error?

In the original code, $class went entirely unused. All of the shenanigans to figure out whether the invocant is a reference are useless.

The design problem with this technique is that it allows you to write:

my $object   = Class->new();
my $otherobj = $object->new();
[download]

What relationship should $otherobj have with $object? Does it have any? It's easy to expect a prototypal relationship between the two, or one where the former's instance data somehow sets the latter's, but there's almost never any code in the copy-and-paste copy constructor to set this.

Why create an interface that does nothing?

Worst yet, consider what happens if someone invokes the constructor like this:

I know that's unlikely, but the copy constructor technique will silently create an object blessed into a package called HASH. Without the copy constructor technique, Perl will happily throw an exception about attempting to bless into a reference. This technique silences useful error messages for no good reason.

As far as I can tell, the only reason this code persists is because someone put it in the documentation as an example of a cool technique, and people started thinking it was necessary because the documentation explained Perl 5 objects as crazy black boxes that require a lot of arcana.