I wouldn't call my position strictly anti-GC. I would simply say that GC isn't the panacea it's made out to be and it is at least in part a false economy for at least three reasons:
1. You may need to tune your VM/GC parameters (as you mention). There's a cost to this;
2. GC can make it harder to identify memory leaks (which are still a problem through, for example, dangling references). I've worked on C++ systems where we instrumented many things including process size, which was basically just a flat line. As soon as it wasn't, you knew there was a problem. And this was for a server that read about ~6GB/second off a NIC.
3. Crashing a program due to accessing unallocated memory tends to give a more immediate signal of a problem, which is more often than not better for development.
> eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about
This is a really interesting example, because it shows the lack of nuance in the anti-GC position. By your logic, because Java's 100ms GC pause times have been problematic (and yes, I'm aware that Java's upcoming GC will boast significantly improved pause times and that it's theoretically possible to tune a Java GC for low pause times even if no one has managed it in production) Go's 5us pause times will be equally problematic. Because a pause is a pause, right--why should we muddy the waters with considerations like "duration"?
Single- or double-digit microsecond pause times completely change the conventional wisdom about the kinds of applications GC is suitable for. There are still lots of hard real time applications that Go's GC won't be suited for, but there are many soft real time applications for which Go would be fine (or at least the issues will be libraries or support for target architecture/platform and not GC).