Implementing lookbehind by reading backwards is not more computationally expensive than reading forward. It adds some complexity to the regexp engine, yes, but that's manageable.
There are some quirks vs. stepping back and reading forward, like the article already explains.
I guess Perl initially just did not implement it this way, whatever the reason was.
> Generally, there are two ways to implement lookbehind assertions. Perl, for example, requires lookbehind patterns to have a fixed length. That means that quantifiers such as or + are not allowed. This way, the regular expression engine can step back by that fixed length, and match the lookbehind the exact same way as it would match a lookahead, from the stepped back position.*
> The regular expression engine in the .NET framework takes a different approach. Instead of needing to know how many characters the lookbehind pattern will match, it simply matches the lookbehind pattern backwards, while reading characters against the normal read direction. This means that the lookbehind pattern can take advantage of the full regular expression syntax and match patterns of arbitrary length.
> Clearly, the second option is more powerful than the first. That is why the V8 team, and the TC39 champions for this feature, have agreed that JavaScript should adopt the more expressive version, even though its implementation is slightly more complex.
regular-expressions.info has roughly the same explanation here: http://www.regular-expressions.info/lookaround.html
I guess I had just assumed that if even Perl didn't implement variable-length lookbehinds, then the performance or implementation cost must have been severe enough to justify leaving out such useful flexibility. What is the tradeoff that .NET and now JavaScript are willing to make?
edit: According to a comment in the posted article, Perl 6 now implements variable-length lookbehinds http://www.perl6.org/archive/rfc/72.html