The main two issues are that a data connection doesn't require user consent (unlike video/audio) and the browser checks all network interfaces as connection candidates (so VPN users on Windows and Mac expose their real IPs). As I proposed in the bug, if we fix those two things, we would be a lot better off.
These requests do not show up in developer consoles and
cannot be blocked by browser plugins
I'm using FF with a WebRTC-blocking plugin, and it does successfully block the proof-of-concept exploit (it's called "Happy Bonobo Disable WebRTC", an admittedly shady name, but there are surely others).
Yes, most of those plugins were made after this test was created. This one just sets "media.peerconnection.enabled" to false in Firefox's settings. However, it means you have to disable WebRTC entirely, not just the STUN requests.
Unfortunately, Chrome doesn't let you disable WebRTC at all unless you recompile with "-Denable_webrtc=0", and Chrome blocking plugins are easily bypassed (see some pull requests in my repo).
All true; but a perfect solution would not involve more prompts to the user. Crying wolf and all that; too many and nobody reads the prompts any more.
The exposure of your IP address(es) is a very mild risk; not in a class with security risks, more like cookies. It just helps de-anonymize you, if you care about that.