I'm not experienced with Lisp, but I've heard that as well. A project will essentially invent its own language with the macros, and once the original developers leave nobody else wants to learn those macros, they want to use their macros. And so the project dies.
That's a myth. Actually there are lots of project with domain specific languages and in the case of Lisp they are often directly embedded. Having OO- or functional interfaces to learn is not much different from learning macros.
USING the macros is not a problem. MAINTAINING them might be a problem, because new people might have a hard time understanding to work with a language which has meta-level programming directly integrated. There are more languages which now are adding some kind of macro facility (example Rust), so there might be now more programmers getting familiar with meta-level programming with macros.
Projects like planners for public transport use special language extensions and if they have a market, they go for a long time. Other example, a specialized CAD system will have its own language extension for expressing generative CAD operations.
Sometimes there are projects which are replaced with different technology. For example a web store generator. But there the domain technology typically changes that some of these sites have three technology transitions in a few years. Every project owner has new tool preferences, influenced by the market. It might look like that old code is not understood, but the problem is actually that the code is no longer fashionable. Writing enterprise applications is largely done by Java and not C++. The reason to replace an enterprise application with one written in a newer language (like Java) has many reasons: technology no longer seen as fashionable, fewer trained developers available, trained developers to expensive, age bias, new libraries not available for the older language, etc.
I am experienced with Lisp, and this is a case of "Short answer yes with an if; long answer no with a but."
Plenty of junior Lisp developers are so enamored of macros that they over-use them. Particularly since macros in Lisp are so both easy to write, and mentioned as a feature unique to lisp, you see junior developers reaching for that as a their first tool. This leads to there being lots of projects as you describe, particularly projects written by a lone Lisp journeyman developer.
Most Lisp style guides say things like "Don't use a macro when a function will do." Most projects written by more experienced developers (particularly those who have experience working on a team) tend not to end up in this state.
> ...author winds up inventing his own undocumented mess of a language, unusable for anyone else.
For projects in which an embedded language makes sense, documentation is important! Also, again, this is a situation that tends to be peculiar to projects written by lone developers because it's very hard to get away with writing a tool that is unusable by other people if you are surrounded by other people trying to use it.
[edit]
This is also partly an artifact of the post AI-winter community being so small and fragmented. When smalltalk style OO was the next big thing, there were dozens of implementations for it in Lisp almost overnight. Reasonably quickly this whittled down to about 2 or 3 popular ones, some time after which people got together and standardized CLOS from the what was left. Arguably the Lisp community is insufficiently cohesive (and insufficiently funded) these days to maintain something like that that now.
Macros killed the Lisp. They never noticed.