Every (Unix/terminal) shell is a Read-Eval-Print-Loop.

The difference is the data structure which is passed around. Is it bytes, Cons, or objects?

No, every UNIX shell is a poor Read-Eval-Print-Loop when compared to what Xerox PARC machines allowed in terms of interaction with the running OS.

UNIX shells don't allow to call functions declared in .so, execute scripts applied to elements selected with the mouse, apply functional algorithms over data.

Well, you can write external commands in another programming language, but then it isn't a REPL anymore.

A lisp repl is not any repl. First, the homoiconicity of the lisp syntax allows you to sumbit structures of arbitrary complexity to the listener, and reuse output from it, even submit it back as code to execute. Second, the error handling mechanism allows you to interactively choose how to resume, and the way the repl and the image work, allows you to redefine the ill code before resuming, which is incredibly useful and intuitive. Say I have an url, and a loop that reads some data from that url, suddenly an error happens, the resource url is changed and I have to update. If I was using slime through emacs, I would be taken to the debugger, which shows me the options to resume. While that debugger is there, I can switch to the source file, tweak the variable for the url, evaluate it, switch back to the debugger, and hit the key for retry. I would have fixed the code without having to stop the program (not even behind the scenes, like with tools that watch the program and restart it). And also within the debugger, in either of Elisp debugger and Slime debugger, I can do many things, among which peek into the locals, copy stuff from there and use in my program to explore the problem. I have heard that in a space mission, NASA programmers were able to fix a spacecraft that was in space, from earth, via connecting to its lisp image over the network.

What do you do when you have to debug a pipeline? You do not have direct access to the data that flows, you need special tools to examine core dumps, and you have to have had enabled saving the dumps beforehand, you need to verify that the command syntax is correct, you have to understand what each program emit, and make sure you filter out all irrelevant data like logging etc., you don't know which part of the pipeline failed, where, you don't know if it is a wrong parameter or the program has a bug. And in order to fix bugs in programs that make up the pipeline, you have to know in whatever language the buggy one was implemented:

  </var/log/my-service.log ag 'Response: 505' | sed 's#(<timestamp>) (<path>) Response: (\d{3}) (\w+)#\1,\2,\3,\4#' | python create_report.py --output-to latex > /tmp/report.tex && latex /tmp/report.tex && dvi2pdf /tmp/report.tex && [ -f /tmp/report.pdf ] && sh /home/gkya/utils/mail_report.sh --report /tmp/report.pdf

In this command line at least six different languages are in use. I just made it up, but it doesn't seem far-fetched to me.