Here's a rough sketchy of my thinking:

After this loop:

for ($index = $start; $index <= $end; $index) {
  $events[] = ...;
}

We do something like this: sort the events, then choose the farthest-future end date.

if (count($events) > $limit) {
  $events = msort($events, 'getDateFrom');
  $events = array_slice($events, 0, $limit, true);
  $longest_possible_end_date = last($events)->getDateFrom();
}

Even if we don't have a hard end date on the query, we know that we can never need to generate events beyond $longest_possible_end_date, because we already have a full result set which occurs sooner than that date.

Then, the next time we go through the loop, we can use the soonest end date of: the explicit query constraint, the reccuring event termination date, or the $longest_possible_end_date.

We can repeat this process and keep bringing $longest_possible_end_date closer and closer to the start of the range, so we have to generate fewer and fewer events.

For example, suppose we have several recurring events.

• We process event A, a monthly event, and generate events for the next 1,000 months. We sort them and pick the last date, so $longest_possible_end_date is now sometime a bunch of years from now.
• We process event B, a daily event, and generate events for the next 1,000 days. We sort them and pick the last date, which is about 3 years from now. So $longest_possible_end_date is now some time in 2018.
• We process event C, a weekly event. We can stop generating events when we get to 2018, so we only need to generate about 150 events, instead of 1000.
• We process events D and E, both daily events, and now the first 1000 events end near the end of the year (they go "B, D, E, B, D, E" 300 times).
• We process event F, a weekly event. We can stop generating events when we get to the end of the year, so we only need to generate about 50 events instead of 1000.