I disagree. Sure, the code is functionally equivalent today, but the next person touching the 'or' version might be less likely to introduce side-effecting computation. The 'if-else' version is completely open-ended.
We need to think about the effect our choices have on the next person who touches the code. Often with a different baseline people make different changes. It's a micro-form of 'No Broken Windows'.
"We need to think about the effect our choices have on the next person who touches the code."
And that next person might be the newbie on the team that doesn't have the business domain knowledge built up over years of working for This Company. So I'll use the if statement to keep intent clear.
Or maybe it'll be someone whose primary programming language doesn't use the || operator. Or maybe, for some unknown reason, it'll be a PHB. So I'll use the if statement to keep intent clear.
Setting the baseline gives you a higher probability of a better change than you would have otherwise. This assumes that not everyone on the team is a newb or a code-dabbling PHB. If they are, there's not much point in writing any code.
If the idea is to keep the intent clear, the or statement is a much better choice, even if less familiar.
"I want to set param to the object property or the default"
is much clearer than
"I want to check if if I have an object property and if I do then I'll set the param to the object property otherwise I'll set the param to the default"
That is just mixing in a lot of noise about how you do it instead of just what you are doing.
We need to think about the effect our choices have on the next person who touches the code. Often with a different baseline people make different changes. It's a micro-form of 'No Broken Windows'.