I'm not sure I follow - how is this different from, say, a native app (desktop or mobile) that's just using UDP like normal? There's a single preflight request per client device, which can usually be satisfied when you load the website itself.
You could handle it with some kind of cookie/token that enables the LB to route to the right place, but that opens a whole bunch of other complicated logic too.
Whereas if the UDP application/server were able to handle it independently of HTTP(S), you wouldn't need any of that.
Doing that with NAT is even trickier. Take a look at the way some firewalls need to configure a DMZ for gaming, or SIP for some examples.
And once you have that permission, you never need to make an HTTPS connection again.
What you do care is that your actual application traffic, such as your login session, and your UDP traffic have some way of being associated with each other, but you have that problem regardless of how the client (whether it's a browser client or a normal desktop/mobile app) gets permission to send UDP.
As an example, the user could visit example.com, load some HTML and JS, send a request to login.example.com, get a session key, send a single HTTPS request to data.example.com exactly once, and then send UDP to data.example.com protected by that session key. You never send HTTPS to data.example.com again; from this point onwards you only send UDP. Coordination between your HTTPS login server and your UDP data server is no different in this model from the native app model.
I guess what I'm trying to say is UDP could work, but I think trying to bootstrap the initial connection/session info with HTTP is probably going to be FAR more trouble than it's worth.