LispWorks has a lot of features in its GC. Years ago it was used in a demanding telco application, an ATM switch. It was also used on a space mission experiment. Generally the runtime is very very nice.
Franz Inc uses Allegro CL in a large database. They tuned the GC quite a bit for that. But there were also other GC demanding applications on Allegro CL, for example in CAD and 3D design. They are now working on a concurrent GC, something which is still rare in the Lisp world.
Mostly because there are very very few people in the world who are able to develop such a complex thing for Lisp (or similar runtimes). Since the market is relatively small and many applications are not overly concurrent, there is very little money to support the development.
I am guessing[1] that GCs are easier to code correctly without the concurrency and that a GC language is already expected to be slower so it doesn't make sense to do a concurrent GC. Also possibly, the language doesn't support concurrency well. Like a Python or Ruby.
[1] just an educated guess. I have no real knowledge of GCs other than skimming how they work in articles and runtime/language docs.
It doesn't actually implement concurrent GC, although what it does implement is far simpler and has a similar effect (low latencies) as concurrent GC.
Each Erlang process has a separate heap that is collected independently; because the process heap is usually small a stop-the-process collection does not take much time.
The downside is that sending messages between processes requires copying all the data that is sent between process heaps.
Franz Inc uses Allegro CL in a large database. They tuned the GC quite a bit for that. But there were also other GC demanding applications on Allegro CL, for example in CAD and 3D design. They are now working on a concurrent GC, something which is still rare in the Lisp world.