Don't apply "Best Practices" without fully understanding the underlying mechanisms.

But feel free to disparage a "best practice" w/o fully understanding the underlying mechanisms so long as you have one case in a trivial (and contrived) benchmark and don't seem to have any clue about the reason for the best practice?

I don't see any mention of these changes causing your application to suddenly run unacceptably slowly. Sounds like premature micro-optimization. Only being able to run that contrived regex several thousand times per second seems like something likely to have no preceivable impact on performance in most situations. Sure, there can be cases where such a dramatic-looking benchmark result for a micro operation can have real impact on practical performance, but those cases are much rarer than many people seem to believe.

Yes, I knew that [x] has been (until recently) not as optimized by Perl as a literal character. I also knew that [$] doesn't DWIM (sadly), and quite a bit about why (one of the more interesting parts of Perl parsing). But you certainly won't find me claiming to "fully understand the underlying mechanisms" of those constructs.

If you yelled at me for making the described changes and had this as justification... Actually, my reaction (eventually) would be to strongly encourage you to spend some effort to more fully understand why premature micro-optimization so very rarely pays off and better understand why it is so widely recognized as the opposite of a "best practice".

I guess your bolded statement particularly bothers me because most changes I make to software don't involve me "fully understanding the underlying mechanisms". And the point of a "best practice" is to prevent me from having to waste time trying to fully understand yet another thing. Don't make changes to software unless you have some confidence that your change isn't making things worse. And test your changes, including for acceptable performance.

So you've tried to set the bar way too high for making changes to software. And trying to set a higher bar for "best practices" is the opposite of what should usually be done.