Here is from Techempower benchmark C# vs Go[1]. To me C# is not looking very impressive. For memory I do not have a better reference than[2]. Here again C# seems to use 2-10 times more memory than Go.
These tests don't seem to specifically test GC, so it doesn't seem to be a good comparison.
Comparing Go and C# as languages don't seem to be the goal of this exercise, either. Instead, the article was making the point that the garbage characteristics have generational components. This is true of C#, so I would expect it to be true of Go as well. If that is the case, whatever Go's current performance numbers are, they could probably be made better by a generational GC.
Isn't GC in some part defines application performance characteristics? Why would pure GC benchmarks be useful if an application with better GC performs worse than application with worse GC?
You don't seem to understand how performance benchmarking works.
Unless you seek to optimize a single application, a benchmark is meant to be broadly representative of a wide category of applications whose performance is dominated by the component being benchmarked.
For instance, an application which allocates no memory is a poor benchmark of the memory allocator, and it is also a poor general representative of program performance if most programs' performance is dominated by memory management.
Comparing Go and C# as languages don't seem to be the goal of this exercise, either. Instead, the article was making the point that the garbage characteristics have generational components. This is true of C#, so I would expect it to be true of Go as well. If that is the case, whatever Go's current performance numbers are, they could probably be made better by a generational GC.