Are you perhaps coming from a Clojure perspective? Scheme is no more inherently immutable than, say, JavaScript. Many Scheme programs I've seen use mutation quite liberally. Immutability is a useful pattern in lots of languages and situations, but Lisp per se doesn't particularly enforce it.
Actually, this expression is non-conforming: you must not try to modify the string returned by cl:symbol-name.
"non-conforming" means you will get different results in different implementation, perhaps something like a nasal dragon, or perhaps an error signaled, or perhaps some more benign behavior.
$ clall -r '(progn (setf (char (symbol-name nil) 1) #\U) (quote nil))'
CLISP Attempt to modify a read-only string: "NIL"
ECL Detected access to an invalid or protected memory address.
Clozure Common Lisp --> #|symbol not found in home package!!|#COMMON-LISP::NUL
Armed Bear Common Lisp --> COMMON-LISP::NUL
CMU Common Lisp --> COMMON-LISP::NUL
SBCL --> COMMON-LISP::NUL
Some implementations will gladly and blissfully modify the symbol name, and your program will break because it cannot intern the original name anymore (not the best behavior for an implementation IMO); some implementation will detect the non-conforming access. Worse could have happened (remember, you are on the Internet so you can be located by geoip/gps/wifi, and missiles silos can be hacked by botnets).
But otherwise indeed in general, mutable lisp objects are mutable, and you can implement mutating algorithms as well as purely functional algorithm. Foremost, you can have an hybrid approach, using what's best to solve the current problem.
I'd point out that Common Lisp, kind of like Smalltalk, is a highly dynamic environment that has historically been used as an operating system in itself. That's one reason why the system is so mutable—you don't want to have to relaunch it even to modify core functionality.
I actually don't view mutation in Common Lisp as a downside. I find writing high performance (usually numerical, but sometimes not) code in Clojure to be painfully obtuse compared to Common Lisp, but I love Clojure otherwise. Writing highly optimized code can be quite elegant in Common Lisp, and I appreciate that when the problem at hand calls for it.
Ah, right, but that doesn't mean the language is immutable to the degree that it would make for a steep learning curve. Mutating cons cells is arguably an obscure feature; you are free to mutate variables, vectors, structs, tables, and so on (even if you might have to specify that you want mutability).
My experience with racket is certainly not one of steep learning curve. Plus it is _thoroughly_ documented. If I had to recommend a Lisp implementation for someone that wants to learn a Lisp it would definitely be Racket as it is easy to install (and works on windows), has great documentation and a super friendly and interesting community.
The only thing I'm not fond of Racket is that compared to CL w/ Slime it feels way less interactive, a step up from Python, but still not CL (nor Smalltalk)
But lets focus on the positive, the OP is highlighting that the trite criticism of non-lispers about parens is bogus.
