1) It's unlikely to accept any x.509 certificates you can get issued under today's CA/B guidelines; and I'm also not sure how many CAs from then are still valid, either because they had too small of keys or they expired
2) I'm not sure if ie5 supports TLS 1.0 and if it does, it's probably not by default, because that how things were back then.
Given these conditions an https handshake is highly likely to fail, and as the server operator there's no way to provide useful information to the user in that case. If they go to your http site and you redirect them to a handshake error that you know they were going to see... That's not useful. You could be secure and not provide service... but then again, your redirect could be MITMed cause http. Or you could provide a useful service with no security.
This is a choice, not a vulnerability.
This doesn't open up any new way to attack a modern client. Modern clients would have google.com HSTS preloaded and not use http at all. But even if that's not available, a MITM that fiddles with the User-Agent to avoid getting a redirect could have fetched the search results via https and proxied them back via http, as long as the client made an http request.
Edit to add: if you could get a cert IE5 would accept, it likely wouldn't be acceptable by modern clients, so you'd need to distinguish clients from the TLS handshake (although, I guess it really is an SSL handshake for ie5?). There's no client identifier in there, but you can certainly tell the difference between modern and ancient; it gets trickier to tell the difference between ancient and pretty old or pretty old and trying to do a fallback handshake.
You can see the full HSTS list here I believe: https://source.chromium.org/chromium/chromium/src/+/master:n...
I just realized after writing this comment that if you can rewrite http headers, you can also stop the redirect so perhaps it doesn't matter.