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.
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.