This doesn't exactly answer your question, but I feel it's relevant information. I did something similar, but I also didn't like using the kill switch. In another iteration I used a [TrustedRedirectResponse](https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Routing%21TrustedRedirectResponse.php/8.2.x) which allowed me to handle my cache issue differently. This worked well for me, but I can't really explain it. :( My understanding is this is forcing browsers to always bypass cache when executing the redirect, but the Redirect itself is cached in drupal until $entity's (my cache dependency) cache is invalidated.

    $response_headers = [
      'Cache-Control' => 'no-cache, no-store, must-revalidate',
    ];

    $response = new TrustedRedirectResponse($url, '302', $response_headers);
    // In my case $entity is a content entity where my redirect $url is generated.
    // In your case you'd add cache dependencies relevant to determining shouldIRedirect().
    $response->addCacheableDependency($entity);
    $event->setResponse($response);