The shell itself is a programming language, it has construct and everything because well, it is a programming language.
I am not a fan of the bourne shell syntax but you can write fairly large programs on it, and the idea itself of using other programs and piping it at the core and heart of unix.
Perl is tied with any modern unix for historical reasons, but it has been criticized for not really following the principles of unix really well.
Yes, heavily-adopted things are often pressured to grow to their logical conclusions. One logical conclusion of a commandline+commands is REPL+procedures.
One critique of the worse-is-better [1] philosophy (Unix), is the design starts cracking more as it's pushed to scale to its logical conclusion.
Of course, maybe the worse-is-better essay is inapplicable (and the author himself argued both sides under a pseudonym or two). And good design is a matter of degree; we could all critique the-right-thing representatives. But here I think it's a useful model to describe what's going on.
In this case, we should also argue about, should software evolve into their any of it's logical conclusions?
I'm a cli ninja (at least for many tasks I need to do daily for a measure.) even though I nearly never ever need it's expanded use cases like arrays or process substitution. For example the latest shellshock was the result of an extended use case where implications of it was not well thought.
"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." - Look at the samples: Emacs, MATLAB, Mozilla, Opera, Trillian, and Drupal. Really?
I am not a fan of the bourne shell syntax but you can write fairly large programs on it, and the idea itself of using other programs and piping it at the core and heart of unix.
Perl is tied with any modern unix for historical reasons, but it has been criticized for not really following the principles of unix really well.