A whole half-dozen, eh? :) You haven't been around long.
Specific code quality is not what I'm talking about. I think you've misunderstood me. Let me try and be more specific and concrete.
The degree to which code written by different authors at different times can gel together depends on the idioms they have in common. In languages without common collection libraries, code needs to communicate at the level of arrays and custom iterators. Languages without a single common memory allocator need have libraries negotiate who owns what memory, and have custom free functions specific to routines and libraries. Languages without lambdas typically reinvent the concept a half-dozen different, incompatible ways.
The amount of friction when trying to compose code or integrate with existing code is proportional to its divergence from the lowest common denominator of all code written in that language. The higher-level a language is, the larger a standard library it has, the more concepts that are shared between libraries and codebases and don't need to be reinvented in each individual code silo.
Go back to C in the dark days of Windows 95. Merely getting a string out of the OS was an ordeal; you could choose to allocate a buffer, send it to the OS, but always prepared to react to a failure and reallocate the buffer when the string turns out bigger than expected. C has no universal string type nor a common memory allocator (you might rely on glibc's malloc on Linux, but you're relying on non-portable convention). This directly resulted in a substantial amount of friction simply interoperating between two binary libraries.
The same thing follows through with higher-level concepts. When higher-level concepts are concrete in the language or available in standard libraries rather than composed out of simpler primitives a half-dozen times in slightly different ways, you lose a bunch of composability. You spend more time writing shims and adapters to smooth away the differences between interfaces.
And code isn't the only interface; your mind is too, especially in a larger legacy codebase. You may understand iterators, lambdas, functors, monads and so on, but in a language without first-class support and standard definitions for these things, you'll find them reinvented over and over again, to varying degrees of fidelity, sometimes under obscure names, which you'll need to discover and research as you dig into code nobody still in the organization has ever had to dig through themselves.
None of this has anything to do with code quality possible in a language. I've had to maintain some extremely high quality assembly. But it wasn't mentally cheap to get into, and a lot of concepts had to be reverse engineered from the code before they could be modified and transformed back down.
The risk with something like Lisp is that you use it as a language construction toolkit. With a closely knit team that grows a codebase amongst themselves, this can be a huge productivity win. But I don't think it scales. And I think history agrees. Excessively malleable languages (including Smalltalk) have not outcompeted less expressive languages, for one reason or another.