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.