Regarding performance. I so very vaguely recall learning it is bad practice due to how the compiler processes it.
Even if there is some performance difference, that would be low-hanging fruit for any compiler optimizer. Leave such micro-optimization to the compiler author.
FWIW, I would be very surprised to find any difference at all between those cases.
It has nothing to do with parsing or code generation or anything like that.
It is because of the way C (and C++) handles expressions, and the slippery-slope for bad code that such constructs encourage.
In this case specifically, C has traditionally not had a boolean data type. Writing if (x == FALSE) has never been a problem -- it is when you then write things like if (x ==TRUE) when things go wrong.
Consequently, the conventional (and correct) wisdom is to let the compiler do its job properly performing implicit boolean conversions as a last step without your help.
That, and the truthiness of the statement isconsidered both obvious and cleaner to read without the extra verbiage.
if (x) ...if (!x) ...
Both are short, sweet, and to the point without ambiguity, just like C (and C++) programmers like it.