I don't know what I was expecting, but one of my most-used command lines, "du -a | grep foo" is pretty uninformative.
% find . -path '*foo*'
But, your detractors will say yours is two processes and theirs is one. Efficiency!
A word is standardized as 5 keystrokes
80 wpm is therefore 400 keystrokes per minute.
Divide by 60 to get about 6.6 keystrokes per second, or about 0.15 seconds per keystroke.
Therefore it would take about 0.6 seconds to type the four extra characters, giving a net savings to use du+grep instead.
And 80 wpm is probably a rather fast estimate; I'd guess that I type slower when I'm writing commands than when I'm entering English text.
Also, what an odd one-liner. What's the use case for this that makes it such a common command: file names and sizes for all files matching a pattern beneath the current subdirectory (and all subdirectories and files within subdirectories matching that same pattern)? Genuinely curious.
The bigger problem is grep. We're told that grep prints lines matching a pattern, great. But then the explanation of the arguments makes it sound, to the uninitiated, like I'm giving "foo" as the filename, because the site doesn't include the actual grep syntax.
It doesn't really explain what the command line is doing. It does seem to do a decent job of telling someone who's already fluent in shell usage the specific meaning of all options given. That's actually pretty important these days where any given GNU util will have flags for every single letter of the alphabet in both upper and lower case.
(while :; do cat ; sleep 2 ; done) <file