There's an element of truth in that, but only in the same sense that all Turing complete programming languages are equivalent or that many programming languages are ultimately instantiations of a register machine, a memory store, and a program counter. The interesting thing in most cases is what you build on top of that foundation.
With Lisps, the value is in the uniformity. That makes it very easy to extend the basic functionality you get out of the box in a way that fits in, using macros and so on.
With various other languages, the value is in the pre-built tools that rest on top of some underlying abstract syntax tree. That covers a vast range of functionality these days: more expressive type systems, a wider range of built-in data structures, actor-based concurrency, low-level memory and port access, and numerous other practically useful language features. Hopefully any given language offers a combination of features that work well together and have natural supporting syntax and semantics. That in turn gives each language its own flavour and means each language works better for some types of software than others, even if ultimately it's usually just syntactic sugar for a relatively simple execution model and an AST.
McCarthy's Lisp:{Python,Ruby}::zygote:adult human
mtts as quoted by Silhouette gets it right IMO. Conversely, S's distinction between extending a language and using the tools (the distinction, to oversimplify, that makes you a Lisp programmer) that sit on top of its core seems to me a confusion of means with ends. Any useful program is a fall from the perfection of JM's insight. This perspective makes me a not-Lisp-programmer. Thousands of developers smarter and more experienced than I have taken each side of this dispute without resolving it; I certainly don't hope to.Lisps allow you to extend both the parser (reader macros) and do transformations on the syntax tree (macros) before it gets compiled/interpreted. In most of the other languages parsing and code generation are very tightly coupled with no easily accessible step in between.
What is important in the read-eval-print loop is the dashes :)
ML I know nothing about, BTW.