Some people will look at this as evidence that Perl should be relegated to one-liners, but I find immense usefulness in combining my more engineered aspects with one-liners, and providing myself with a "project evaluator". What I do is create a simple bash script which just calls perl and sets the library include path to the project lib, includes a few useful things to always have (Path::Tiny, Try::Tiny, Data::Dumper, etc), and passed the rest of the args to Perl. Using DBIx::Class for SQL manipulation and/or using complex API client libraries I've written combined with the abilities of perl to do things easily as a one-liner is amazing.
Still mostly fine so long as you know you're only dealing with 7-bit ASCII, IIRC, but Caveat Emptor.
It's easier to just say File::Slurp in mixed company so people immediately know what it is if they look it up, rather than them be confronted with a grab-bag of functions.
That's a business culture thing. If you set the expectation, that it's okay to do that, people might do that. If you set the expectation that it's not okay, people shouldn't.
The equivalent C and Python are likely just as ugly (given that the equivalent python might be using a far too complex range statement or put it on a single line using : and ;, which is possible...).
That said, as bad code goes, that's not really that bad. The only non-standard things are <> and $_, and if you don't know what those are, you really haven't done the minimum of learning about the language (<> might be somewhat exotic in that form depending on the codebase, but $_ is not something you can get way with not knowing about). In all, the major problem with it is that it's not commented and uses poor variable names, which is something every language needs to deal with. I would write it like so if I wanted it on a single line (but I would probably use 2-3 lines):
But I would likely opt for the following if doing it myself: Assuming I was using <>, which I generally don't since File::Slurp is usually available and clearer.