Wouldn't this make it pretty easy to have browser clients unknowingly participate in DoS attacks?
WebUDP wouldn't necessarily make the situation any worse.
1. The receiving end must consent to receiving packets by completing the DTLS handshake required by WebRTC.
2. The browser enforces SCTP congestion control to avoid spamming large numbers of UDP packets. Basically, it'll start throttling you when it detects packet loss.
The only way this could be done safely is if you are required to establish a TCP connection, and then "upgrade" it to UDP. There are too many pointy sticks that developers could impale themselves on, with the side effect of creating DDoS vectors.
Since it's restricted by origin (probably using literally the same mechanism CORS uses) and over HTTPS, a malicious actor can't DDoS anyone but themselves.
If you're really worried, maybe extend it to allow the server to limit the duration of the permission and the maximum bandwidth, but I think you don't need that.
EDIT: Oh, oops, binding to the hostname doesn't help because you can just repoint your hostname in DNS at someone else. You'd ideally need to bind it to the IP, in which case you definitely want it to be a time-limited permission. (But I think that attack is also feasible, though a bit harder, with the handshake-before-each-UDP-connection model. Just have the attacker set up a custom DNS server for their domain, which for any hostname sends you a low-TTL response pointing to the attacker's HTTPS server, and then a higher-TTL response to the victim. Each user gets pointed at a random hostname within that domain.)
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.
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.
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.
UDP is arguably faster in some ways that is handled, provided the application load is managed well.