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.
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.]