Well, yes and no.
In the thread Cheap idioms it has been mentioned by Aristotle and Ignatz amongst others, that the acceptability of such an idiom depends on the level of (self-)documentation. This can be either a simple comment (just a few words, otherwise more verbose code would be better IMHO), or, by wrapping the idiom in a subroutine with a self documenting name.

On the condition that warnings and errors are properly reported, I don't see any obvious trouble for maintainers.

To clarify, let's say I see the line of code I don't understand, which is commented with "slurp in file" and I recognise a filename being used there. Now either the code "just works", or it breaks with a proper error mesage ("no such file at line 123").

In the first case I might get interested in why this works and learn something (mind you!), or just take the working for granted.

If there is a failure, I have a clear signal where to go looking: "No such file" still means that I have to trace the file and path names, rather than debugging the "slurp" line.

The bottom line: in my opinion there is a blurred line between knowing what goes on and just using "an idiom" - honestly, which Perl user is fully aware of the C-level system calls underlying Perl's open() builtin? And do we need to know?

--
Cheers, Joe