Almost nobody uses goimports or godoc as a declared dependency; they're tools, not standard library components.
It's perfectly possible to implement cryptography without touching x/crypto; std includes SHA2, HMAC, an AEAD interface, ED25519, and, of course, Go's entire TLS stack. Arguably there's too much cryptography in std (almost nobody is better off directly building on cipher cores and signature algorithms). Thankfully: most Go programs don't implement cryptography, which is dangerous even with Go's relatively solid library interfaces.
I used the Go crypto primitives in /x to build a perfectly serviceable document encryption mechanism inside a document storage service. It was relatively painless and worked well. I can't really comment on how secure it ended up being - you can always build a crypto product that you can't break.
The standard advice is always "never write your own crypto" and it's very good advice.
It's perfectly possible to implement cryptography without touching x/crypto; std includes SHA2, HMAC, an AEAD interface, ED25519, and, of course, Go's entire TLS stack. Arguably there's too much cryptography in std (almost nobody is better off directly building on cipher cores and signature algorithms). Thankfully: most Go programs don't implement cryptography, which is dangerous even with Go's relatively solid library interfaces.