Summarizing the cause and solution as discussed in the comments.
Cause: The primary cause is that the map is rendered on an HTML5 canvas and there is no native mouse events for individual items rendered on the canvas. As such the Bing Maps Web SDK has code to handle this. Everything works as expected when using a mouse. When using a touch screen, on a mobile device or computer, the right click event maps to a long press. In order to support the right click/long press event, there the firing of the click event has to wait a period of time to make sure the user isn't trying to do a long press.
Solutions: Use a different event, such as mouse down or mouse up as these don't need to do any calculations/waiting.
Some history for fun: The Bing maps Web SDK was released 7+ years ago. I was the program manager for the SDK. Initial development took over a year, that's the era of technology used when this SDK was designed and needs to be backwards compatible for. A goal was to be able to support rendering a lot more points on the map. All web maps up until then were using traditional DOM elements for rendering (images/svgs) which would run into performance problems after a few hundred shapes were added to the map. HTML5 browser adoption was on the rise and predicted that by the time we finished development, would be within our minimum threshold for market share support. At that time I recall having a tough discussion around not officially supporting IE10 as HTML5 performance was horrible, and its market share was decreasing at a fast pace. Being Microsoft, we knew that whichever browsers we committed to supporting, we would need to support for a long time. Every time we tried to remove support for a browser previously in other map SDKs there was always a decent number of customers who were stuck on the older browser for some reason, like working on a machine that was locked down, or some legacy product that embedded it that can't be updated. Most, if not all of the Bing Maps Web SDK features still work today on the original set of browsers as documented here. When we were doing development, web worker and WebGL support was low (~56% of market share) and not an option, so we had to use the HTML5 canvas directly with CPU level calculations (UI thread). We had to be creative in how we balanced stability and performance. Supporting mouse events was an interesting challenge and the solution the dev team came up with is pretty cool and comes from an old school gaming industry solution for collision detection. Basically, it renders a second offscreen canvas of the map, and uses colors to define layers and shapes. I believe the red channel is used to define the layer ID (you can have up to 256 layers rendered in a single map view), while blue and green combinations were assigned to each shape, which meant you could have up to 65,536 shapes rendered within the displayable map view (shapes that weren't in view wouldn't need to be rendered, so the map could support loading and tracking a lot more shapes). When a mouse event occurred on the canvas, the color for the same pixel on the offscreen canvas would be retrieved and used to decode the layer and shape ID that was intersected. This made for high performance mouse interactions, with the main exception being around supporting right click on touch screens (long press). I recall us trying different wait times. I wanted little to no wait time, and although it might have been fine for some, it didn't align with accessibility guidelines and would have been a pain for a decent number of users. When we released it, this web SDK was the fastest one available for nearly 2 years. Eventually WebGL support grew enough, and the Azure Maps team went that route (You can try that one out here: https://samples.azuremaps.com/)