That's the point. If the user declared the variable himself he knows it.
If it is a demo-code he hasn't written himself and this user is a very very beginner
showing both versions and explaining it will teach him this as a side-effect.
And again: as an expert it is a peace of cake to understand what
not really, it is also natural language, it's common to compare stuff when you speak
if the wind speed is more than 80Km/h then don't go sailing
if you name your variables appropriately then the code is easy to read
if (windSpeedKmh >= 80) {
// ...
}
Anyone (besides politics) get what a truth value or a comparison is.
I've been working with kids or teens (and older people) and it has never been an issue
I consider it a "win" if some user can even be shown that boolean variables and values explicitly exist, have standard names, and can substitute for expressions. Many beginners don't even know that. Let's be honest, C/C++ is not the ideal beginner language because of such features (which are welcomed by experienced programmers).
Once they understand that, choices like the redundant use of == with boolean variables, should be easier to understand and use or not use.
We educators face the problem that many aspects of understanding are co-dependant, demand a parallel learning. So it's difficult to demonstrate specific aspects of a feature, without involving other features which also need to be demonstrated.
Because of this, I think that a demo code that is designed to explicate a certain feature, should have some latitude and flexibility in what other features are employed.
It is not possible to teach everything in one lesson.
The == however makes it clear with what type of variable one is dealing with. Personally I'm always using == and !=; but except for some 6 months (4 hours/week) courses in 6809 assembly and Pascal, I have no formal education in programming.