Um, that gets rid of the global performance penalty but (as near as I can tell) keeps the local performance penalty, so I don't agree with "no need".
If you are writing a parser that is spending most of its time applying regexes against potentially large strings, then the local penalty is plenty big of a penalty. It would be very nice to be able to use $& and $1 etc. w/o the local penalty with the caveat that those variables no longer work correctly if you modify the string most recently matched against (no, I'm not talking about being able to use $1 in s/// w/o the local 'copy' penalty).
I vaguely proposed a /k option to prevent copying (and an option to prevent capturing, a somewhat related problem). I don't recall seeing such in the announcement and didn't find the announcement to check again.
I don't even mind if $1 etc. can't be used directly. I'd just like to be able to disable the copying of the entire string while still being able to pull out the parts based on @- and @+ (a simple module could make these nearly as easy to use as $1 etc.).