assuming you're not trolling, it's user-unfriendly because novices are used to changing settings in GUIs. changing settings in a bash script is a qualitative difference, and paradoxically leaves novices more helpless, despite being a more powerful tool in principle.
they don't know any of the syntax or semantics of bash, so they may as well be pasting something written in Kanji. they must put their trust in some random person on the internet who told them the incantation, that it isn't malicious or outdated or irrelevant. if it doesn't work, they have no idea what to do, or how to even begin to debug it, or how to undo it. they don't know if the change they made is permanent or if it will go away if they delete the line and reboot. they don't know about man pages, or the difference between .bashrc and .profile, or what the PATH environmental variable is, or what an environmental variable is full-stop, or what sudo means, or file permissions, symlinks, shebang lines, package managers, or any of the myriad incidental complexity which might crop up when you try to run some shell command from stackoverflow.
because often it isn't as simple as running that shell command. it turns out you need to run it with sudo, or apt install some missing command, or it uses some syntactic construct that doesn't work in your current shell, or a grep option that doesn't exist on your version, or you're in the wrong directory, or you need to activate some systemd service first, or it says to pip install something but actually you should use your system's package manager, or X or Y or Z ... experienced users run into little snags like this all the time and fix them without even thinking about it. do an experiment for me right now: go through your bash command history and find some command you used to solve some minor problem. then look at the commands before it for the failed attempts and workarounds and diagnostic steps you did. you probably forgot you even did those. then ask yourself if a total novice could have done them. the answer will be "no".
compare a GUI: a GUI settings dialog will have options labelled in English, and leans on well-understood semiotics of checkboxes, dropdown menus, sliders and so on. those constrain the possible types and values (compare with stringly typed shell commands), and it's clear how to undo them afterwards if necessary. they inform you of both the current state of the system, and how to change it (contrast: viewing the state of the system vs changing the state is two different terminal commands).
novices have a perfectly rational fear of screwing with things on the terminal.
This is a very valid point. When I first started with Linux, pretty terrified of screwing something up fundamentally with the terminal.
Most terminal commands are not particularly intuitive either. I'm technically very competent but before I learned how to code, I would have no way of knowing that "sudo" gives you admin privilege, or that "cat" shows the contents of a file.
For the average person, "sudo" or "chmod" are pure gibberish, and "cat" is an adorable pet.
Like this is part of the code for creating a mouse scrollwheel control script:
"if [ ! -f ~/.imwheelrc ] then cat >~/.imwheelrc<<EOF"
You can't be serious if you pretend that a non poweruser is supposed to understand what -f or cat, or E0F are supposed to mean.
In my experience, a GUI settings dialog normally will have options labelled in Brazilian Portuguese, which is even more friendly. The command line, on the other hand, is always in English (though its output is often in a mix of English and Brazilian Portuguese).
(Your experience may vary; people from smaller countries might have only a partial translation of the GUI, or even none at all.)