I see this in this way:
By definiton, OutOfRangeException should be use to when potential problem is logical - occurs because of wrong code or definition. OutOfBoundsException is for runtime.

Example (see also note in "OutOfBoundsException class" article):
<?php
function prepareData(PDOStatement $s) {
    $x = $s->fetch();
    if (!isset($x['secretColumn'])) 
        throw new OutOfRangeException ("Secret column doesn't exist! Verify table definition and query.");
}

I tried to write a snippet that would be detected at compile time, but was unable, apparently due to my PHP engine's interpreted nature. The creator(s) should have provided a usage example (for end-users) or pointed to PHP sources for an example of where/how it's used. None of the provided examples, to date, reflect an exception detected at compile time, as this class asserts.

IMO it's hopeful at best to expect a compiler to detect an illegal index in a dynamically-typed, typically JIT-executed, enviro. Since when is there a strict contract of what indexes should be considered "within range" and how would the compiler know about this contract? Also, how would we try/catch that in the compile phase?

SPL also provides the OutOfBounds exception. If this class, its parent, and OOB have little distinction, then does SPL need all 3?

Exemple :

$calendar = new Calendar();
$calendar->getMonth(15);

I would probably repeat @jacub's answer, but I see the distinction as following:

`OutOfBoundsException` you throw, when _you_ _set_ bounds and do not wish them to be crossed by an external entity, but they may be.
Example: you ask for a number in range [1, 6] and user input 0 or 7 or what else. You throw an exception indicating user error they could amend.

`OutOfRange` you throw, when you expect value within allowed boundary, but actual operation fails.
Example: You are trying to access external API call using information provided by the API itself, and it suddenly tell you that the reference key is not pointing to a valid object. You throw an exception indicating internal failure that the user is unable to correct.

In both cases, the key word is "you throw". Both exceptions are generated at runtime, but the latter describes a situation that should not happen, ever, if a system is configured correctly.