I do a ton of code reviews, often as part of an interview process, less often, for embedded developers. Conditionals written with literal lvalues is something of which I tend to take note. You're right, it's not natural, and it's less readable, but there's usually a reason why people do it: experience. If you often work in weakly typed languages, or those which allow for weird coercion in conditional statements, it's sadly often easier to form a habit which guarantees fewer bugs than it is to say "I'll always type the boolean equality/strict equality operator."
"But why don't you use better languages, then?" Because in many cases (low-level resource-constrained systems programming), it's much, much easier to deal with these weird gotchas than to attempt to get exotic  languages such as Python, Ruby, Java, and sometimes even C++ (heap? who needs a heap??), to work. Even in cases where you're able to get these languages to work easily, you're just forcing yourself to become intimately familiar with the internals of some language with which you'll ultimately wind up wrestling . Normally the point of such languages is to abstract away the system. This is the exact opposite of what you need in these environments.
"But it annoys me when people use literal lvalues where they don't need to." Ah, but this is the rub of forming a habit.
1: I'm mostly sarcastic in my use of the word "exotic" here. Don't go crazy, now. ;-)
2: Though to totally contradict myself, I will say that both Rust and Go look very, very interesting here.