Don't even think about it. If any of those even is consistently more efficient, the difference will be so small it is hardly going to matter. The key here is that it's a very concise way of doing what it does. In this case it is a oneliner, but in general, it doesn't matter how many lines an idiom takes (the Schwartzian Transform rarely fits in a single line, f.ex) - just that it is concise way of expressing a certain action. Don't confuse that with golfing: an idiom is not about saving keystrokes, it is about saving "brain cycles". The idea is that a) it is conveniently short so that people do use it and b) when you see it used in a snippet, you immediately know what it does just by the unique look of it.
It simplifies communication between the original programmer and the maintainer of his code.
I agree that it is visually much more readable and I thought well, if it is faster also, cool. but i don't agree with you on one point: if it is even 1% faster, i'll take it for a script that has to process 100 000 files in a row. Otherwise, for little scripts (read that process very little data) I agree, I won't bother.
Well, you have a point about the 100,000 files - at first glance. But - if you are processing 100,000 files, is the slurp idiom really the best place to optimize? Don't you think you will be able to get much more than a 1% per-file-open speed up by optimizing some other, more heavily used part of the script? And if you really have optimized all else so well that the file slurp can make any difference - maybe you should be using C, instead of Perl.
Remember - premature optimization is the root of all evil. Don't optimize before you need to. The corrolary of this is that you shouldn't try to micro-optimize parts of the script in anticipation of possible performance bottlenecks. When you do hit one, profile your script and work on the most processing intensive part.
Remember: programs are letters from one programmer to another. The fact that computers can execute them is only incidental.