The most common use case I have seen is basically ensuring that specific data is attached to *all* logs, while not delegating that work to your other code. Here is a very crude example of a logger that does this some: https://play.golang.org/p/nMHpXAAVc8

If that logger were used throughout your application, your handlers wouldn't need to concern themselves with things like the requestID or the User ID when logging. That logic is isolated to the Logger type.

The DB is similar - you don't ever attach a DB object to a context, but you could make an argument for creating a transaction and attaching that, in which case you can rest assured that *everything* you do in that request will be contained within a single transaction. I don't really do this often, but I could see it being a reasonable decision to make.

The key here is that in both of these cases we are attaching something that was created specifically for this request, and we destroy it once the request's lifecycle ends. That is, in my humble opinion, within the spirit of what context values were intended to be used for.