Exactly! But you would not have to dredge if the author had written Packet_Foreign->new. This is the root of the objection.

(ref $obj)->new
The code tells that you need to determine the type of $obj to figure out how the call to new is resolved.

Obj->new
The code tells you where to start to resolve the call to new. This can be of great benefit to the reader in some situations.

$obj->new
The code obscures the author's intent. Could he have written Obj->new but didn't just because of mindless imitation? Could he have written (ref $obj)->new but didn't just because of mindless imitation?

I give you rir's observation: When the code is bad, the documentation is worse. So I find your statements to rely on the documentation unconvincing. If truth and beauty don't exist in the code, I won't count on finding them in the documentation.

I am sorry that I unable to make my point to you. Last fall when I first read merlin's criticism of this idiom as Cargo Cultism, I was resistent. My first thoughts: it is no big deal; it's just a little convenience; it is in the Camel; it has never bothered me; and merlyn is being exceedingly fussy.

But since I really had adopted the usage without critical thought. And since I had, still have, no good argument against high standards, especially where it resolves to an idiom, i.e. think once -- type many. I did consider and quickly found fault with the idiom. My reason to deprecate the idiom is different from merlyn's and, I think, a much stronger one.

I won't write $class = ref $class || $class because it supports the thoughtless use of $obj->new which can be obscure.

There are other views: tilly's posts A Cat's eye view of OO and Re (tilly) 2: Paradigm Shift - Dual Use Constructors and their associated threads. Also Re: (Ovid - minor code nits) Re: Adding autoloaded methods to symbol table with using strict refs.

Update: True confession time: When first I adopted the dual method trick its cuteness appealed to me. So I used it unnecessarily.
Fixed minor typos.