It’s pretty easy to write Lisp “functions” that are not actually functions because they invisibly depend on each others’ side effects. The goal of FP is to prevent that.

It depends on how broadly you define 'functional'. Back in the day just having closures and anonymous functions was probably enough to qualify. But nowadays Javascript and any other number of scripting languages have those features too. I can't think of any respect in which Common Lisp encourages or requires a functional style to a greater extent than, say, Javascript.

It's also worth mentioning that the Common Lisp standard does not require implementations to implement tail call elimination. The pervasive use of a functional style in CL would therefore give rise to programs with performance characteristics that could, at least in principle, vary greatly between implementations. (I'm aware that most popular CL implementations do optimize away tail calls in practice.)

Common Lisp programs can mutate variables, function bindings, and slots of various objects such as cons cells, arrays, structures and CLOS objects. Programs can execute sequences of forms as if they were statements, for the sake of their side effects, and can conditionally and repeatedly execute such statements. There is a form called tagbody which can contain labeled statements that can freely branch to each other using go.

Common Lisp doesn't require implementations to provide tail call support, so functional programs that express iteration using recursion may be severely limited in the inputs that they can handle; they would typically be ported to Common Lisp by a rewrite using iteration.