Hi,
I am not a DDD guru, but I’m still not convinced that bounded contexts are necessarily a consequence of object-oriented modeling (although translating objects between bounded contexts probably is).
The Ticketing concept from your example is an elegant solution to the “false cognates” problem, as Eric Evans calls it, but it only works if everyone means the same thing by Ticketing. If, for some reason, we end up with two different Ticketing concepts, we are back to the same problem. In fact, that’s exactly what happened with the Charge object in Eric Evans’ own example. Yes, Charge is an object, but the real issue lies in its purpose (billing customers vs paying vendors), making it a conceptual problem. We are then faced with essentially the same questions: Should we reconcile the two concepts into one, or are they serving different purposes? Or would we be better off with two distinct conceptual models, introducing bounded contexts once again?
In that case, isn’t the real question not conceptual versus object-oriented modeling (concepts surely win 
), but rather how we deal with different contexts (how to share concepts)?