It seems to be the difference between Normal (Workstation) and Concurrent (Server) Garbage Collection strategies. Basically the Workstation approach runs into issues in many extreme cases. And massively Multithreaded scenarios (like ASP Webservers) are prime examples of such an extreme case:
https://social.msdn.microsoft.com/Forums/en-US/286d8c7f-87ca-46b9-9608-2b559d7dc79f/garbage-collection-pros-and-limits?forum=csharpgeneral
Note that concurrent GC has natural issues with weak references and defragmentation, but if that applies to the .NET Core implementation is beyond my knowledge. There are all kinds of improvements the .NET Core team could do to the code and this goes into the area of designing a GC memory manager.
Maybe it only defines how many concurrent threads will be used for the tagging part (with the workstation default being 1). It might also include some modified memory allocation strategies to avoid issues like defragmentation.
In either case the actual collection will by nature have to run single-threaded, halt all managed threads and will be limited by memory speed, not CPU speed.