Context is really good so long as what you're storing deserves to be there. For example, any UUIDs you generate for request tracing or anything like that. Once you start storing actual request data like users, or session data, etc. then it's a problem.
I'm of the opinion that (if you're writing web services) anything related to the request should just be passed to the function using it. Shouldn't be stored on context and passed along 20 middleware handlers. If you need to share state this way then it's a failure of your design. Putting the meat of your business logic in multiple handlers is not the way. A handler is how you get the data into your application, then you can forget about them. But some people don't really understand that and start having authentication middleware, session middleware, user middleware etc. Just pointless complexity.
For you the problem is the very fact you're able to pass values through context transparently or that some people abuse it passing all sort of data that should be passed in better ways?
For me, using context and stuffing and retrieving things from it is the most painful part of go.
If anything from go should die in a fire, itβs Context - well, the key value storage anyway. The canceling part is fine.