Just having UDP somewhere in the stack isn't sufficient. The reason game protocols use UDP is because (among other things) they can precisely define when to block on missing data and when to ignore it and keep going.

For example, lets say a client is sent 3 sequential packets, p0, p1, and p2. Sadly, p1 has been dropped by network goblins. What should the client do? Well, that depends on what is in the packets. If p0-2 are messages like "append this value to a list", then it's pretty important for them to all arrive, and in-order. But if p0-2 are sequential updates to the coordinates of something then it doesn't matter if p1 is lost; you get the right final state regardless.

So in the case where you're interacting with something that's continuously moving (like, say, a person in VR) you can essentially never block on transient packet loss because there's always an update coming 10ms later. That's a big deal in terms of making the experience feel fluid.

What's wrong with HTTP is that there's no real benefit to using it in a real-time environment. There's no point. We use reliable UDP abstractions today to accomplish this. Everyone does. There are countless articles on why TCP didn't work for video games, or of the ones that use it today, it's in an extremely limited sense.

I can't think of a single reason why you would go out of your way to serve HTTP over UDP for the purpose of communicating to a user agent for s/video games/virtual reality/, because no one has done that in over 20 years and if it was a good idea, it would have been done by now. But no one does it. Because there's no point.

You severely underestimate the application of real-time positioning needs in 3D software. "Twitch-shooter" is an amateur way to describe such an application; real-time positioning is desirable anywhere. Interp only gets you so far.