Well, it varies from source to source. E.g. if we look at John Hughes' working definition from his 1984 paper 'Why Functional Programming Matters', then functional programming is programming with only pure functions with no side effects, assignment, or mutation. No mention is made of 'monad' or 'functor'.

The rise of effect handling systems like monads in functional programming languages since the oughties was driven by the real-world need to, well, print 'Hello World' to the screen. And different practitioners have different opinions on how far to take effect management. Haskell is just one extreme, but there are several FP languages on the spectrum.

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.

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.

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.)