That's fair. That kind of Perl is also very different than the kind of Perl you would use to write Mojolicious applications, or system utils, or daemons. Those features are very specifically for quick one-liners[1], and in some cases don't even make sense outside of that.
> I use Ruby for text processing now, because it's easier to read than Perl, but I loop on stdin with IO.readlines, each and split.
In a one-liner, or as a small source file? Doing that in a small source file is also common in Perl, but if you're doing that as a one-liner, I think you're not making it more readable, you're making it less so, as the executable/language specifically support features to make that easier to do which you're ignoring, obfuscating the important parts of the code with verbose obvious bits. It's sort of like making sure to spell out et cetera instead of using etc even when texting or using Twitter.
1: BEGIN actually has some important uses in Perl, but under the covers for most people, so they never have to deal with it.
For a really simple case, leveraging a module in the language to do the heavy lifting and do something per line. If I want robust CSV conversion for a TSV, loading up a CSV module in Perl or Ruby and letting it act on each line (after appropriately split on tab, and with the newline removed from each line, both a single command line switch away) is a very small one liner that's appropriately leveraging the language to do something that's hard with common shell utils.
There's a whole world of ways to leverage a powerful ecosystem with the built in one-liner features of Perl and Ruby. If you don't often find yourself doing a lot in the shell, then I can understand having a hard time imagining a case where it's not always better for a small source file, but for anyone whose responsibilities also entail a fair amount of system administration tasks, it can be extremely helpful.
If for nothing else, the number of times I've used autosplit or a nice regex to parse a complex line into an appropriate SQL statement I can output to another file, check, and then run is quite large. These often amount to a single regex and print per line, and are on some other log portion I've already grepped out, so generating the boilerplate for the line looping is actually more code than the actual statements that need to run. Add to that the times that there's no maintenance needed because the scripts are used to fix a one-off problem, and there are specific use cases where one-liners make sense. For a lot of people's workload, that might not be the case, but I definitely see the cases where it is.
I use Ruby for text processing now, because it's easier to read than Perl, but I loop on stdin with IO.readlines, each and split. It could be less efficient but I'm not parsing billions of records. I value readability more than one liners.