Braintree.js cuts down PCI scope as much as tokenization. We've worked with banks and auditors to make sure that this doesn't add any headaches for our merchants.
We recommend that you don't store or log credit card data encrypted with Braintree.js.
As far as PCI compliance, Braintree.js minimizes your PCI scope as much as tokenization. As long as you serve your site over SSL and maintain adequate security around access to servers, administrative passwords, etc., when using Braintree.js, you'll fall under SAQ A (the lowest possible PCI scope for online merchants).
I've run Go in production for a web application, and I'll say that Go is not a great choice for this task. The built in HTTP server doesn't have a way to shut down gracefully, there's not a good zero-downtime restart story, and the standard library SQL package (and abstractions on top of it) has some nasty warts that only show up under concurrent load.
If you build a webapp in Go, be prepared to spend a lot of time monkeying around with problems that are solved issues on most other platforms.
There's another large issue with queueing requests on the dyno: when the app restarts, all the requests currently queued up on that dyno get dropped and the client receives a 503.
He wants "x is declared but never used" to be an error that halts compilation. Go's philosophy on this[1] is "if it's worth complaining about, it's worth fixing in the code."
Any merchant that accepts credit card payments must be PCI compliant. Even if cardholder data never touches the merchant's servers, the merchant still falls under the scope of SAQ A[1].