From a design standpoint: Because the ergonomics of shells and regular programming langauges are very different. 99% of your interactions with a shell is going

From a design standpoint: Because the ergonomics of shells and regular programming langauges are very different. 99% of your interactions with a shell is going to be single commands, or short piped chains. Economy of keystrokes is something that a lot of people want here, which is why cd and ls are both that short to type. Most programming languages require at least () to run commands, since not requiring that seems sloppy. This makes your two most common interactions twice as long to type. Shells have also been built to help glue applications together, and are more concise for the easy versions than most programming languages, sometimes heavily so. Most programming languages, (outside of maybe perl and ruby), don't make this use case anywhere close to their top priority, but shells do, trading off other things like a simple syntax for bitwise OR. In another sense, shells are exactly what you describe, it just happens that the most popular languages for them happen to be sh/bash/zsh/fish etc, which make a different set of tradeoffs than the 'traditional' programming languages. I'm only partially aware of the history standpoint. My understanding is that before awk, shells (sh, mostly, IIRC) were about the only scripting level languages on various Unixen.