(Unfortunately, the straightforward attempt  $str =~ s/[+-](\d+).{\1}//g; doesn't work.)

How come the straight forward way doesn't work?

Because the regex compiler will attempt to compile the entire  [+-](\d+).{\1} regex (the 'search' regex of the substitution) at compile time, but the  \1 backreference of the  .{\1} counted quantifier sub-expression is not known until run time, when something may be captured that it can actually refer back to. OTOH, the  (??{".{$1}"}) 'postponed' extended pattern is specifically designed to both compile and run at run-time.

BTW: The use of  $^N is, IMHO, 'safer' than the use of  $1 in the sub-expression  (??{ ".{$1}" }) (making it  (??{ ".{$^N}" }) instead) because  $^N equals the contents of the most recently closed capturing group and will not change (semantically) if the relative positional relationship between that capture group and the use of  $^N does not change; whereas adding another capture group anywhere before the  (\d+) group will change the semantics of  $1 because capture group counting will change.

...but the \1 backreference of the .{\1} counted quantifier sub-expression is not known until run time, when something may be captured that it can actually refer back to

I think it's worth pointing out that in other cases this works just fine.  For example, in /(\d+) \1/, a placeholder for the captured value is compiled into the regex.  I.e., the following will match

print "123 123" =~ /(\d+) \1/ ? "matched" : "didn't match";
[download]

It's just that with more complex patterns, it doesn't seem to be implemented. (I don't see any compelling reason why - in principle - the count in question here couldn't just as well be compiled to refer to a captured value.)

And how come \\w rather than \w works?

The double backslash is just because it's in a double-quoted string, so a literal \w remains in the runtime constructed regex pattern fragment.