Having never looked at Perl's C implementation of this, I think it's just a matter of not writing support for it, because it is "touchy" code after so many minor tweaks, and supporting both directions may need yet more maintenance.

Theoretically, any regular expression can be processed in reverse; that is, when searching for /def$/, you can look backwards through the string for the end of a line, then for an 'f' before it, then for an 'e' before that, and so on. This holds true no matter what the complexity of the pattern may be.

In practice, there's a lot about a regex matcher engine that must be written with an expectation of the direction you're walking through the pattern and the source string. Parameterizing the direction or stride as +1/-1 is perhaps not trivial. So they punted: simple strings with an obvious anchor (current spot, end of line, etc.) can appear to be scanned backwards by calculating where they would start and scanning forwards.