First of all: I agree. There are many things in Go that feel like a hack. For example, it is common (and idiomatic) to use a map with empty values when you want to use a set (unordered and unique values), because the map's keys are a set. I personally dislike this, and some aspects of Go are like this.
However this blog post is about how good core language design leads to unplanned patterns that are useful, like HandlerFunc and the private interface hack.
One person's "unplanned patterns that are useful" is another's "this is a potentially dangerous hack that could lead to all manner of headaches in any non-trivial program with even just a few hundred lines of code, let alone thousands or millions."
The sweet spot for Go is in the hundreds to a couple of thousand lines of code. Unix philosophy and all that. Leave the monolithic MLOC monstrosities to Java.
People write MLOC monstrosities in Java because they can. You get some boring financial topic and some sub-par programmers and they'll write as much garbage as the language can possibly sustain.
These things are a testament to how safe and simple Java is as a language.
Not having massive crappy code bases is a negative sign in terms of how reliable and easy to understand a language is.
None of the things you mentioned are "potentially dangerous hacks." Using maps as sets is common in many languages and there's nothing wrong with it. Adding a guard method to an interface is pretty clear and it works well, as well.
Yes, it's best to use the smallest tool (orthogonal language and libraries) for the job because it's less to test and maintain, and more likely to be correct.
However this blog post is about how good core language design leads to unplanned patterns that are useful, like HandlerFunc and the private interface hack.