Yes, and that's an alternative that's been proposed (by me and independently by others). The consensus is that it could be done using autobox. That's my personal preference, with the option to turn off a warning for it:
$z = $not_defined->arbitrarymethod()
Method not called at ...
I personally think that's preferable to a whole new operator; the idea is to make it work in much the same way that sending messages to nil does in Objective-C: it does nothing, and returns nil (which equivalences to 0 in numeric context). For Perl, it'd do nothing and return undef (in list context it'd return an empty list).
I'd argue, as you do, that using it in a limited scope makes it not very worthwhile - and that's why I'd use it everywhere. With an added pragma to allow us to warn on messages to NIL, I think it'd be quite reasonable to do that.
Consider: the objective of this is to eliminate code by making message-to-NIL safe. Adding the code to only use it certain places is essentially the same as saying if (defined $foo) and the point was to not need that.
I'd say that if you feel uncomfortable with jumping out of the plane with this chute, so to speak, this approach isn't for you. I've used it a lot in Objective-C programming and I find it really simplifies things, but much as using $_ as the default variable, either it really works for you or it doesn't work at all.
I think it's mostly getting used to the different semantics. I love how much more compact the code is in Objective-C when I don't have to worry about sending messages to undef. But I can equally understand the desire to have that throw an exception. The "I'll add a new operator to provide this" seems like a harder way to have both options - but it does specifically call out "In this case, I am explicitly deciding to do safe deref", so...
I'l try to get something working so it can at least be tried.