This is mostly wrong. Lisp is mistermed "functional language" due to schools which teach freshmen some subset of a Lisp dialect which they must use in a pure way to solve homework problems: no variable assignment, no loops. The second thing you hear from people after "functional language" is things like "oh yes Lisp. I remember all the recursion; it was elegant".

Lisp is in fact organized around the idea of a function being a pure function and it was that way from the beginning.

This is why the sequential execution of forms with side effects has dedicated macros/operators with names like prog and progn. These provide "the program feature": giving step by step procedural instructions that tell the machine what to do, rather than an expression which computes a value. The only reason to use (progn x1 x2 ... y) is that x1 x2 ... have side effects. If they only compute values that are discarded, the whole thing may be optimized down to just y.

Also, there is a funny quirk in the terminology whereby Lisp people still refer to the arguments of cond as being "cond pairs", even though you can write procedural bodies consisting of multiple forms, and it has been that way for decades:

   (cond
     (this-condition do-this and-do-this yield-this-value) ;; triplet, not pair
     (that-condition do-that and-do-that yield-that-value)
     ...)

The "cond pairs" terminology persists because cond was originally restricted to pairs! Except for the aspect that it evaluated the conditions in left to right order, it was inherently oriented toward handling the cases in functional programming: upon finding a true expression, it evaluated its result counterpart, and yielded that value. In "pure Lisp" programming, cond will still be used that way.

Of course, even ancient Lisp had rplaca and rplacd to mutate conses, and set and setq to mutate variables. The 1960 Lisp 1.5 manual describes arrays (indexed from zero (damn it!) and mutable).

Calling Lisp "least functional" is completely silly, since it was the first tool which enabled computer scientists to translate pure recursion on paper directly into executable code. There are countless languages which might take such a title, by virtue of having no support for functional programming.