The author doesn't demand that his readers implement AES or SHA2 directly. So, what I would do is start with a simple, secure design based on an AEAD like AES-GCM, which is also in the Golang standard library. I would accompany that design with very strong warnings that substituting AES-GCM for anything else is likely to destroy the security of the design. Then, when I wanted to teach about generically composed MACs, my HMAC example would involve replacing AES-GCM with AES-CTR+HMAC. At no point in the book would the focus of one of my chapters be a design that was dreadfully insecure.

I would also divide the book into two parts, the "easy" part and the "hard" part. The "easy" part would get readers to the point where they can safely use TLS, reliably PGP-encrypt something, hash a password, and invoke NaCl (which is part of the go.crypto package). I would probably spend a whole chapter on how to use Golang's TLS library, for instance. Most readers that are picking the book up so they can solve some business problem would probably never need to get past the "easy" part, and I would encourage them not to.

I would remove from the "hard" half of the book protocols that were insecure. An unauthenticated DH exchange is a poor basis for a cryptographic transport. Slash, cut, gone. A naive password challenge-response protocol doesn't solve anyone's business problems. Slice, snip, gone. In their place, I'd probably add more discussion of key exchange algorithms, with particular attention paid to how easy they are to get wrong.