effectively the same place at this point. There's so many "standard" libs in /x that trying to constraint to "just the standard lib" has to include /x to be actually useful.
They're not at all effectively the same place, and much of what's in /x competes with third-party packages, which are on a somewhat level playing field in that both /x and third-party code have to be explicitly brought in to a project as a dep.
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.
