My issue largely about the scalability of pipes. They're ok for basic tasks, but not great for complicated routines:
1) You've only got one send and one return. (well, arguably more if you include stderr and exit codes, but they have their own limitations in addition to the aforementioned)
2) They're too insular from each other; different files dotted about that needs to be loaded into the memory then executed. It adds quite a massive overhead. Granted this isn't an issue for the kind of jobs you'd write shell scripts for in the first place, but it does severely hamper this kind of model in terms of scalability. But then we're back to the age old issue of performance vs convenience.
I will concede that the second point is more an issue about implementation rather than concept though. But if you were to write a lower level implementation of Unix pipes, I don't think it would pretty much end up with Perl functions (which, to be fair, you suggested yourself). I say Perl specifically because you can create a function without specifying what values to accept (see example below), which is akin to the 'dumb' strings read in from STDIN.
sub PerlFunc() {
foreach (@_) {
$i++;
print "Parameter $i == $_\n";
}
}
So I'm not really saying that pipes isn't the "right approach". Just that it isn't always the best approach. But for things like system administration, pipes are invaluable. Not just because the tools are already written (ie the wealth of command line applications), but also because it's quick to express yet highly readable.
I'm not really sure if that answers your question though (or even if I've said anything you don't already know).