If it falls back to JNLP2 then the secret is exposed over the wire and thus the encryption can be broken.
There are approx 28% of connection attempts that will fail due to the cookie and about 5-10% that will fail due to challenge-response encoding issues... the cookie one should have been fixed if you use the latest remoting.jar on your agents...
If an admin has enabled JNLP3 on the master because they want to keep transport encrypted, this is a bad thing. For the 10% who are opted in to the A/B testing, they will get slower connection establishment.
Given all the issues I have identified with JNLP3 I am now of the opinion that we drop it and go straight for JNLP4 (subject to an A/B test on JNLP4), so there is no value - to my mind - in continuing with the JNLP3 A/B testing and consequently no value in exposing users to it (obviously JNLP3 is more encrypted than JNLP2, so we cannot disable it until JNLP4 is merged into Jenkins core... and even then we should not disable it until after the A/B testing on JNLP4)