The code below
if(str1 == "abc") {}
can be converted to
if(hash(str1) == 0x8732e) {} // assume hash("abc") == 0x8732e
to obfuscate the code.
But they are not equivalent when hash collision occurs; e.g., str1 = "xyz"'s hash value is the same as "abc".
That is true theoretically. But is it an issue in real-life when the method above is used to obfuscate code? Is it a well accepted obfuscation method?
The example hash digest you gave is wayyyyyyy too short (20 bits, or about a million possibilities), so you'd get collisions far too often and, worse, anybody who decompiled your program could trivially produce the correct strings (or, at least, strings that are acceptable due to hash collisions) just by brute-forcing the likely input space.
"That's a silly objection. It's just an example..." you might say, but it really isn't. I've found, and exploited, this exact type of weakness before. For example, there was a mobile app that used a 32-bit hash function on user inputs to try and hide what inputs would produce what outputs. It took under an hour to write, and run, a program that brute-forced the search space and found inputs that mapped to every hash digest the app was looking for.
In essence, this is much like trying to store passwords securely. There are definitely differences - passwords are rarely very long, while hardcoded strings in a program can be, and if you're performing the string equality test frequently then you can't afford for it to be as slow as a good password verify function would be - but a lot of the same parallels hold. Use a strong hash function, not just resilient to collisions and reversal but also ideally one that isn't so fast its possible to brute-force the whole search space. For short strings, use a salt so that people can't just look up the value in a rainbow table.
Now, as for actual obfuscation: this technique is one (of a great many) that obfuscation can use. It's usually not very effective, especially when implemented weakly (see my second paragraph), and has enough performance impact that it isn't usually used except selectively in places where the slowdown isn't a big deal. Obfuscation in general is a non-solution; at best it slows down reverse engineering enough that by the time the RE is complete the codebase is old enough nobody cares, without causing undue performance or program logic bugs in the meantime. In practice, though, it's usually not that good.
That doesn't really do a good job at obfuscating. If you check against specific strings, those strings probably will occur in the RAM at some point (even during normal usage). An attacker can simply hash the strings they find in the RAM of your program, find a collision, and replace the corresponding parts of the code with the string they found.
Furthermore, pretty much every reason to obfuscate code is stupid – but that's besides to point.
What you should see is that there is a risk of failure. Namely when a hash collision occurs. Because of the way hash functions are designed, for probabilistic calculations we can assume the output of the hash function to be random for every input we haven't tried yet.
If there are several hash values the hash of a varying string are compared to, you can calculate the rate of failure for that comparison using the approximative formula of the birthday paradox  where [
]1
(source: quicklatex.com) is the size of the codomain of the hash function and 
(source: quicklatex.com) is the number of different values the varying string will take.
Once you got that probability for every string comparison in your program, multiply them and call the number you get 
(source: quicklatex.com) . The probability that the program will fail is . If the program will be executed [
]4
(source: quicklatex.com) times that way, the probability that it will fail is http://quicklatex.com/cache3/98/ql_9d24cd1aa3adc352b991541de5630a98_l3.png.
If you value the small amount of obfuscation more than you fear the consequences of your program failing with the probability of http://quicklatex.com/cache3/98/ql_9d24cd1aa3adc352b991541de5630a98_l3.png, do it. Otherwise don't.
if (true)or something similar.