Wow.
1. Have you written or debugged C sockets code? Because if you have, I doubt you would be dinging him on not wanting to do that.
2. He doesn't want to handle C/C++. I would say that most people who write application code are with him.
3. Yeah... I'm pretty sure Python, an interpreted language, is slower than Go, a compiled language. Even with the progress PyPy is making, I doubt it's going to beat Go.
The author needs no age defense. He makes a ton of valid points for why you should try out Go.
PyPy is an optimizing JIT compiler; 6g/8g is not an optimizing compiler. I'm pretty sure one could construct examples in which PyPy beats Go for this reason (try something that relies on loop-invariant code motion, for example).
Additionally, PyPy has many garbage collection algorithms, while Go has a stop-the-world mark-and-sweep collector.
PyPy is an amazing project, but it is my understanding that the Python language makes certain guarantees (particularly around thread safety) that will hamper the speed of any implementation for a long time.
Go is still really young, yet it's plenty fast. There's plenty of room for it to get much faster.
You don't say exactly what you're referring to, but I assume it's the GIL. The GIL exists because Python threads share a single global namespace, and synchronizing atomically on hash tables for module lookup would be way too slow. If you create isolated contexts (like goroutines, but without shared state), the GIL won't bite you (edit: the degenerate cases that folks like David Beazley has described notwithstanding, but those aren't part of the language semantics and have more to do with unfortunate edge cases arising from the way Python's runtime interacts with the OS scheduler).
The problems with making Python fast mostly have to do with its complicated semantics, particularly around things like name lookup; the GIL doesn't have much to do with it.
Interestingly, I predict Go will have a much tougher time here, unless a form of goroutine is created that can't share any state at all. PyPy has been able to do a lot of garbage collection work precisely because it doesn't have to do concurrent GC. Unfortunately, Go crossed that bridge and can't really go back at this point.
Not to downplay these criticisms or to imply that Python isn't a great choice for many of these requirements, but the things you've mentioned of Go's compiler and garbage collectors are (as I understand the intent of the language designers) simply the current stating of being and I believe are both known (and planned) targets for future improvement.
The author needs no age defense. He makes a ton of valid points for why you should try out Go.