Again pick your poison.
The phrase "pick your poison" is misleading because it suggests all poisons are equally fatal. And these two poisons are very, very different. (Alcohol is a poison, and when taken recursively can indeed be fatal, but that's not the usual outcome, nor is it usually a deterrent.)
With the "always false" semantics, a fundamental building block of the language has perennially astonishing semantics in situations that will be routinely encountered by all users. (We've seen languages where the `==` operator has semantics people can't understand; we don't want to be them, or have to deprecate `==` in favor of `===` because the language failed so hard the first time.)
With the second, the performance will sometimes be mildly surprising when some wise guy thinks he's being clever and writes some ridiculous code, like a recursive value list. Then he'll be told to cut that out, and life will go back to normal.
This argument feels to me like "let's snatch defeat from the jaws of victory." For years, we thought it was impractical that we could unify values and references. But we are now 95% of the way there! Substitutibility is a sound, intuitive generalization of `==` over both refs and values.
While we're on the subject of fantasy, let me call attention to another fantasy that we've been engaging in: that somehow values can remain this "weird, off-to-the-side thing." In Q-world they were -- and when you were writing code, you always had to be aware of whether you were dealing with values or objects (and generic code had to learn new rules because they might be dealing with either.) But that's not the world we've built (thankfully!) Here, values will be a common, every day occurrence (Optional, LocalDateTime) that all Java code will have to deal with. (They're Objects!) We have to give people a sound, intuitive model for dealing with the union of refs and values, because they're going to have to deal with that. And we're almost there, as long as we don't blow it.
I realize that we started out hyper-focused on the performance aspects (because there'd be no point in doing values in the first place if we didn't care about performance.) But, users will not thank us if we routinely choose confusing semantics because its faster. Now it's time to focus on delivering a programming model that makes users say "why didn't you do that 20 years ago" -- and we can do that. This is winning; let's take it.
