I do. It happens to align nicely to the way popular spreadsheet calculations label their columns, and many non-geeks can make sense of it.
What are the chances that one day we have a pragma unfeature which disables such stuff?
I hope the chances are low.
When maintaining code, I have to be aware of what all the operations do under all the pragmas in scope. Which is already complicated enough when dealing with nested scopes that have use bytes; and no bytes; in effect.
And then we strict, warnings, utf8 (and no, utf8 is not the opposite of "bytes", that would be too easy), use 5.010 and other versions. Oh, and can you remember which version enables strict by default? was it 5.12 or 5.14? Do you even remember where that is documented?
The proliferation of catch-all(-ish) pragmas like common::sense and Modern::Perl don't help at all, because none of them is a de-facto standard, so you have to remember (or read up) about each that you encounter in foreign code.
Long rant, short summary: The need for pragmas is an indication of design smell.
If we want to make Perl 5 actually simpler in the long run -- and I do think that's a worthy goal --, we shouldn't make it more complicated in the process.
So rather deprecate stuff (with long enough deprecation periods to give even slow-moving companies the chance to crawl along) than layer more complexity on top of it.
A finishing thought: I never had a bug in my code from 'z' incrementing to 'aa', and I've never seen a SoPW here at the monastery where that behavior caused a bug. A much more worthy target for deprecation would be this one here:
That is, an empty regex matching the same as the previous match (instead of disallowing it, or matching the empty string), which is especially annoying if it's not obvious that $re is empty.
Update: Ok, I couldn't resist: Making Perl 5 simpler, more transparent and generally more modern requires boldness and breaking backwards compatibility. Since the Perl 5 community strongly values backwards compatibility, Perl 6 was created to take this pain off of Perl 5. These days, most Perl 5 hackers have lost faith in Perl 6 (for which I can't blame them), but if they do want a modern Perl, they will have to face at least some of the pain they were trying to avoid 13 years ago. There is no easy path that leads both to evolution and backwards compatibility, and missing out on either of those two will cause pain.