Ive found reblessing can be useful in a couple of circumstances. One is when dealing with stuff like delayed loading. For instance if you have an object that has a "lite" and a "heavy" representation and the transition from lite to heavy is expensive it can be useful to have the object metamorphize itself from the lite to heavy on demand.

You could do the same thing with an internal if() but then you are duplicating method dispatch in an inefficient way in that you are adding an if() that shouldnt be there.

Another, related use of reblessing is for the purpose of "freezing" an object in a serialization tool. You may have an object that simply cant be represented conveniently in one form, so you define a secondary class with an "unfreeze" method for the purpose. With AUTOLOAD the frozen class can unfreeze itself on demand by converting itself and reblessing when a method is called on it.

As perrin points out elsewhere both of these mean you have tight coupling between the classes, but for these type of purpose thats pretty much a given. I see this in a sense as a specialized form of a factory. And in an object/class factory you also have tight coupling.

A last use for reblessing that I've used is as an attribute on privately created references without using method dispatch on the blessed objects. In that case I see nothing wrong with it at all. It can be convenient at times to use bless as a way to attach an attribute to an arbitrary reference without changing the contents of that reference. Of course you can also add insideout objects but that can be more hassle. It basically depends on which side of the abstraction layer its on, if its totally private to your code i dont see the problem, if it "leaks" past your codes abstraction layer then it probably is a problem.

All of this is for specialized stuff where IMO the normal rules dont necessarily apply. But as a general rule using rebless gratuitiously is IMO unwise