These could be initialized later down now, which might make the code easier to follow.

This isn't quite right:

• We should only enforce the end if we have more than getRawResultLimit() results. If an event recurs 3 times and then has an end date, we'll artificially set $enforced_end to a few weeks from now.
• We should set the enforced end to getDateFrom() not getDateTo(). We could have 1,000 events ending in an event from 2018-2028. In this case, we'd continue generating events until 2028 the next time through the loop, but can stop in 2018.
• We should set the enforced end date to the getDateFrom() of the last event in the list, after sorting and slicing. The end date of the last generated event might be too soon (as in the first case above) or too late (in which case we'll do more work than we need to). Even if it's correct, we may have a much better (equally correct and sooner) end date after sorting and slicing.

1000 should be $this->getRawResultLimit()

Specifically, I'd expect the code to be something like:

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

See T8394#118074 for discussion.

Unused.

I think we should retain this code, and that it's desirable to show 100 results instead of 1000 in the list view.

Users are rarely interested in 1,000 results, showing 100 is consistent with all other applications, and 1,000 results will always be slower to generate than 100. It shouldn't be a matter of multiple seconds, but the difference between 200ms (feels fast) and 2000ms (feels slow) is pretty big, and the value of those 900 other events is probably almost nothing.

Downloading and rendering 1,000 full events on mobile is likely quite slow, too.

Don't we want it to persist after each recurring event generates its ghosts?