We're trying to make it easy to write unambiguously correct programs.

In general, we assume that your program is parsing output. A return code of 0 means "the output is formatted correctly and parseable, you can continue and parse it", not necessarily that the command produced the desired result.

If we returned nonzero on any error, programs would have no unambiguous way to distinguish between cases like "php is not installed" and "you don't have permission to see that object". To correctly handle errors in a granular way, they'd have to do something like this, accepting parsing ambiguity:

if ($err) {
  $maybe_result = try_to_parse($stdout);
  if ($maybe_result looks like it's probably a valid result, hopefully) {
    handle an application error??;
  }
}

We could use specific error codes to indicate specific conditions, but we can't always control what code we exit with, and codes used by the shell or PHP runtime may be emitted by those layers before we can execute any code. Error codes aren't obvious to a lot of users (many users don't know how to use $?, for example).

In other cases, there's disagreement about what is or isn't an error (e.g., is "no results" an error?).

The implemented semantics are the easiest semantics to use when trying to write a correct, general-case program.

If you're satisfied with a less-correct program, or you have a less-general case where any error can be treated as a failure, it's easy to wrap the call in something which promotes any error response into an exit code.

If we changed the semantics, it would become easier to write a less-general/less-correct program, but harder to write a more-general/more-correct program.