I think one can extrapolate this to make an argument that this problem is the reason we rarely see LISP take off in a big way in a business context.
LISP is incredibly flexible. The ability to use macros to build DSLs without ever leaving the language, and have all the tooling designed to work with the language able to work within that DSL, is a game-changer.
... but what it changes the game into is "If you're working solo you can bend the whole language around to fit your mental model, but if you're working in a group you now have every engineer creating dozens of (probably unsanitary) bespoke macros to bridge the gap between their problem and their mental model today and the end result can become indecipherable to a new user, which jeopardizes a business project."
Paradoxically, flexibility can kill a large project. Large-codebase projects with 100 engineers don't need multitiools. They need what the army needs: an M4/M4A1 5.56mm Carbine with mass-produced ammunition. And they need it because when a fellow software engineer "falls in battle," it's in the company's best interest if you can pick up their weapon and start shooting immediately without having to learn the eighteen abstractions they hid the trigger behind, even if that makes your day-to-day work a little slower because there are upper bounds on how you can modify your weapon.
They're not planning for your needs; they're planning for your needs and the needs of everyone after you who will pick up your weapon and wield it when you're gone.
One can absolutely work in groups using Lisp. There are a lot of examples for that. Often the groups don't need to be that large when working in Lisp. Code in larger projects tends to be more compact. I heard for example of 1/10th of a large (1000 persons) comparable C++ project at Lucent many years ago.
I'm sure it can be made to work; I'm saying the extra flexibility means you need someone making sure everyone's either on the same page or knows how to get there.
I'd be interested to know what approach Lucent took to wrangling the complexity.
Let's assume they had 10 times the people and something between 5 to 20 times the code size. Going from 100 to 1000 people adds a lot complexity. I would think that adding good and experienced managers is important. Keeping all these people aligned, avoiding code duplication, reducing dependencies also needs to be addressed on the organization level. One can make it work, but some of the consequences one can't avoid. Though, it has some positive sides, too.
But then you'll need a lot of tools and architecture to deal with that. To reduce the code size to write, they probably would need to add frameworks, code generators, model-driven architecture, domain specific language, ... lot's of tools. Let's say you'll need to persist C++ objects into a database, they probably used an OO-database (at that time) for C++ with a special query language. Otherwise they would have used a more traditional relational database, either map things to an object-oriented persistence framework or write SQL. Tool building/usage is key, I would think.
LISP is incredibly flexible. The ability to use macros to build DSLs without ever leaving the language, and have all the tooling designed to work with the language able to work within that DSL, is a game-changer.
... but what it changes the game into is "If you're working solo you can bend the whole language around to fit your mental model, but if you're working in a group you now have every engineer creating dozens of (probably unsanitary) bespoke macros to bridge the gap between their problem and their mental model today and the end result can become indecipherable to a new user, which jeopardizes a business project."
Paradoxically, flexibility can kill a large project. Large-codebase projects with 100 engineers don't need multitiools. They need what the army needs: an M4/M4A1 5.56mm Carbine with mass-produced ammunition. And they need it because when a fellow software engineer "falls in battle," it's in the company's best interest if you can pick up their weapon and start shooting immediately without having to learn the eighteen abstractions they hid the trigger behind, even if that makes your day-to-day work a little slower because there are upper bounds on how you can modify your weapon.
They're not planning for your needs; they're planning for your needs and the needs of everyone after you who will pick up your weapon and wield it when you're gone.