Basic answer is if there are complaints with the garbage collector causing stalls or other hiccups, then moving to a faster one could help.
Now, this implies that a new one would, ipso facto, be faster. That is not guaranteed. But, garbage collectors have gotten quite effective in modern times. Extra memory helps, of course.
The current emacs GC can introduce long pauses, so I’d be happy to see something which improved Thant, and I have seen annoying increased memory usage in long emacs processes so experiments in this area would be welcome.
Is that an actual problem, though?
Maybe I just don't push Emacs that far, but I have never felt GC performance to be much of a problem on even remotely capable hardware (say, anything at least as fast as a Raspberry Pi model 2).
Plus, Emacs allows the user to configure the frequency at which the garbage collector kicks in. Tweaking gc-cons-threshold has been entirely sufficient for my needs.
To your point, though, I suspect better async processing would be of much greater benefit.
EDIT: Apparently my experience is not universal -- see below: https://news.ycombinator.com/item?id=15803046