But this is nothing more than a benign style preference.
Sorry, but I think you must have missed the bit of LanX's post that I quoted, so I'll re-quote it here:
At $work (where the word "ternary" provoked empty glares)
I have no problem with people choosing a particular style -- well, not too much anyway :).
I do have a problem with programmers "simplifying" their preferred style under the justifiction that those that come along after them may not understand it.
And I have even more problems with people advocating that everyone should dumb down their code in order to make it accessible to the lowest common denominator of programmer skill sets. Be that done under the auspices of 'best practices'; or 'modern Perl'; or Perl::Critic; or any other set of non-personal rules or guidelines.
And the reason I have a problem with it is because it demeans the dedication and perseverance that it requires for even half descent programmers to acquire the education and skills that make them such. It encourages (and even enshrines!) the viewpoint amongst those non-programmers and 'did a bit once many years ago' semi-skilled programmers (think:managers and personnel types), that all too often control the purse strings (think:recruitment and education budgets), in our industry, into believing that programming is easy and that any ol'post-grad that had sufficient attendance on a half-credit basic programming or CompSci course, is sufficiently skilled to design, write and maintain code.
Finally, all of your examples are professionals using their jargon with other professionals. Any good doctor will speak quite differently when talking to non-medical staff or a patient. Perl, because of the nature of the language, is often used by Perl "non-professionals"--sysadmins, web designers, and others who only spend a small part of their time writing Perl code. If this is your context, it makes sense to write the code with that in mind. It would be foolish not to.
Sorry again, but that just doesn't make sense.
Anyone who needs to read your code with a view to understanding it well enough to base business decisions upon that understanding, is acting in a professional capacity. As such they should be sufficiently educated to understand the code, or willing to expend the effort to acquire that education.
And if they are not making business decisions based upon their understanding of the code, what do you care if they do not understand it?
I'm most offended by "Perl, because of the nature of the language,". The fact that Perl is an accessible language -- designed to be so -- should not prevent the recognition that is a fully capable professional language usable for the construction of highly complex software.
And just as with any other profession, the products of the programmer's skills require a certain level of education and/or aptitude to understand before you can hope to safely maintain, modify or extend them.
Nobody would deny the non-programmer sysadmin from learning just enough Perl to allow him to knock up a few scripts to simply his daily workload; or the hobbyist webmaster from learning enough to add a bit of dynamism to his website. But trying to use that ease-of-entry of the Perl language as reasoning that professional Perl programmers should code down to their level is just crazy. Wrong at every level.