This is cute, but I think (someone will correct me if I'm wrong) that the real idiom is: things that would be singletons in Java are instead servers managing a channel in Golang.
Why incur the cost and complexity of a channel if what you are doing doesn't require it? Go's sync.Once just implements the check-lock-check pattern. It doesn't use a channel in the background.
In fact, it is better to use sync.Once to reduce the risk getting the semantics of check-lock-check incorrect. :)
[edit: It occurred to me that the parent may be speaking about architecture and not about the singleton's design. From an architectural perspective, there are much better patterns in golang than a singleton.]
The beauty of Go's channel design approach is how it isolates responsibilities. It's not just about synchronization. A great example is Rob Pike's lexer.
When passing singletons around, you are communicating with shared state. Sometimes, there is no way around it.
