In part, this is due to Haskell et al. are statically typed, which provides a higher safety guarantee than dynamically typed languages like erlang.
Lisp, especially in it's early implementations is highly imperative. This is why when people talk about Clojure they always talk about Immutability, it's part of what forces a functional style on the language.
And Lisp is highly imperative even today.
As a result, "functional" has become pretty much meaningless when describing a programming language.
Plenty of people will disagree with it too.
functions are invoked in an encapsulating way, and no state is kept between function-cup-up-segments-of-code, but there is a R.E.P.L that (replies) when you invoke a (parens) which is, in LISP-land known as a program.
However, now that I have mind-dumped that ^ I recall haskell and erlang also being called "functional" but I don't know their syntax any more than a chimpanzee knows that the sun is round.
Note that the above definition says nothing about how functions are to be evaluated: strictly, lazily, memoizing previously computed results, or using magic. No general-purpose programming paradigm can make such decisions for the programmer.
Lisp doesn't actually exist. Lisp is just axioms. You run an implementation of Lisp allowing various operations. Some flavors actually have (practically) zero mutability. You just create functions and cons cells and the rest of the world gets built on top of those.
But, pure functional systems are useless (to be purely functional would mean you can't even do I/O... your program would just heat up the computer, which, in a way, is its own form of output, so you can't ever be fully functional).
Every functional language gets non-functional at some point for data processing, bootstrapping, loading/saving programs, and the best functional languages even have optional mutability constructs for performance (see: !). You can't create the most performant data structures possible if all your operations require path copying, but mutability should be reserved for internal high performance library creation and avoided in business logic/application level code to make systems easier to reason about.
And pure languages aren't useless. Not being able to do I/O can be good for many purposes. Pure Haskell is still able to model computations involving I/O, which are then executed by a trusted external runtime. There are benefits to disallowing arbitrary effects, which is also why several new languages take purity even further and disallow infinite recursion.
Now, I repeat, how exactly is Lisp “just axioms”? What are the axioms in question? The mathematical ignorance of some of Lisp's proponents never ceases to amaze me.
Heck, Haskell was barely ever mentioned.
Not to mention that the whole idea of functional programming was introduced to the programming world with McCarthy and Lisp.
(Except if you want to say that "Lisp is not functional, it supports many paradigms" -- but I find that tired. It is, at its core, functional).
Lisp is not much at all like these languages. Nor is Erlang, though it is vastly closer.
Out of curiosity: Would you consider Prolog a language in which you can do “denotational” programming?
The awkwardness I'm talking about comes primarily from the non-orthogonality of Scala's features. For instance, there are situations where subclasses and implicits are both reasonable alternatives for a given programming task. On the other hand, in ML and Haskell, it is often clear which language feature is the right tool for the job.
I think Prolog counts here, too. But it's a weirder one.