I'm reminded of that joke about playing all the right notes, but not necessarily in the right order.
Although there is often some room for rearrangement, the order in which operations appear in code, broadly correspond to the order in which they must be executed so as to produce a correct outcome.
Call-by-value is little more than a natural expression of this principle - the arguments of a call, which represent its inputs, are evaluated before the call itself.
It's difficult to grasp the basis on which any other system of evaluation is thought to be "more efficient" or "safer" by default.
Obviously it is possible to contrive situations in which it may seem to be more efficient if an argument were not immediately evaluated, but this often ignores the computational inefficiency of analysing the code and deciding whether such opportunities exist. In the example given, the two modes of evaluation actually don't produce equivalent outcomes - one locks up into an infinite loop unconditionally, the other only maybe so.
It also ignores the fact that we do not always need to simply tolerate inefficient orders of evaluation under the call-by-value regime - instead, the programmer can rework the code so that evaluation occurs explicitly in an efficient order. Any difficulties this entails, are likely to be less than the difficulty of working with a language where the order of evaluation is never consistent.
I also read Jason Carr's answer above with interest, and what it makes clear to me is that certain thinkers on the subject presuppose why programmers use 'calls', and presuppose that calls can or should be used only in the fashion of 'pure functions' which transform arguments into return values, with no 'side effects'.
Unfortunately, from the point of view of most programmers, the idea that manipulating global or shared state within a call is a "side effect", is as curious as the idea that drunkenness is a "side effect" of drinking beer. In fact, transformation of shared state is the primary purpose of most programs.
Calls are not only used for transforming arguments into return values, but also for orchestrating access to "shared state" that exists external to the current scope (and perhaps external to the current program or even machine).
Where shared state does exist, the programmer must be able to reason about when shared state is being read or rewritten, so as to coordinate that access correctly.
The full information about what shared state is involved, and terms on which such coordinated access to it is being done, is not normally available in the code itself, so the computer must simply do as the programmer says, in the order he says.
And that's why we come back around to call-by-value, because as I said above, it is simply a natural extension of the principle that the order of operations is important to the correctness of the program, and there appears to be no other sensible approach than to evaluate the arguments, before evaluating the calls which employ those arguments.