What scares the Shell out of people?

Artefacts of the long and idiosyncratic history of Unix.

We have so many powerful, stable, widely-available Unix tools and standards, but also plenty of inconsistencies, variants, and arcane caveats; enough to help us... surprise... ourselves in creative new ways. See that cliff you're currently falling off? Yeah, someone went down that road when you were still eating chalk in kindergarten. (Or perhaps you fell off it once before, when I was eating chalk in kindergarten, but it was so long ago that you forgot you've been there done that :-))

Worse, there's no adult supervision, only user manuals. Within Shell's neon-lit environs, one must learn to tread with care, creativity, and cool calculation.

One must learn to accept the silent echo as reward for success.

Why go to Shell at all?

Several of us already get by just fine with a few memorised spells from Shell. That's not a bad way to live, but we miss out on tremendous everyday value that we can unlock with the Unix way.

For there exists a vast no-man's land between memorised tricks and large scale "designed" solutions; wherein no single software tool can really solve all the problems we encounter.

Yet, any modern *nix PC has all one needs to adequately and speedily tailor-make solutions for almost any problem we may encounter in the underserved no man's land.

Solutions that we can use effectively until we truly hit the kind of scale problems or domain complexity that merit use of specialised tools.

Unix nature is deeply Functional

The Unix tools philosophy naturally leads to functional architectures that can scale almost effortlessly. And functional programmers could do worse than learn to exploit such power.

I'll just leave you with Douglas McIlroy's answer to "Read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies.", as seen in More Shell, Less Egg:

tr -cs A-Za-z '\n' |
tr A-Z a-z |
sort |
uniq -c |
sort -rn |
sed ${1}q

A purely functional, automatically buffered data processing pipeline, built with standard reusable parts, written in 1986, directly usable on today's computers.

Imaginative Functional Programmers (aren't we all?!) will find striking parallels between the facilities, concepts, and design principles available in their $Langs, and their *nix environments.

No surprise, because in the dreamy mists of time, the wise hackers of Unix lore, and SmallTalk lore, and APL lore, and Lisp lore, and Forth lore etc... were all different, but they were all together, too.