It gives the fuller perspective. The Go libraries are something very new. People who developed the libraries know them inside out. Outside of that group of people, there's certainly much less knowledge about them. A lot of the claims in the article about the full coverage of some standard in some Go library versus the incomplete one by the given C++ program obviously come from somebody who invested enough time to study the standards and (at least) study the implementation inside of the said libraries. That is, something like that either you know or you can just say authors claim that they adhere to the standards -- which ones, how much; you can't know, much less you are able to compare.

So, for me, that is somebody who didn't follow the state of Go libraries, it was much bigger new information in the presentation the author's certitude that some library covers everything of the standard (good to know how much care was invested there!) than the fact that when somebody has already made some very good tools he can more easily use them then probably anybody else who'd start without such a deep knowledge.

My own takeaway was "now that I know that at least some libraries are very well thought-out that's a good argument to consider when deciding about the use of Go in some future project." Still it's to weight against the learning curve and the quality and ease of use of the available libraries in other more common languages. In that light it's still good to know that the author of the presentation is really very competent.

Not directly related to your question, I also applaud the author's honesty in describing the problem he solved: first, the underlying assumptions changed: I can imagine that the main reason for fetching the data to the local disk in 2007 was that then fetching the data directly from the remote storage was much slower than it is now, making his current approach impossible then. Second, it's not that the original design was as inefficient as the later suboptimal modifications made it. Third, it was a project in which for a while nobody wanted to invest the time to. That's the convenient point to jump in and demonstrate what you can do with the new tools and your knowledge and time. Once you change the equation, a product once almost without the future can become a basis for future much more successful projects.