Although one could argue that register_argc_argv=1 is sufficiently rare for most applications that this doesn't matter in practice? I don't know.
I'd defer this to someone else who has more experience with this.

Although one could argue that register_argc_argv=1 is sufficiently rare for most applications that this doesn't matter in practice?

Generally speaking, deprecations go through slower code paths (e.g. FCALL instead of ICALL / UCALL), since the expectation is that they'll become gradually less used (since they'll be removed).

In this specific case register_argc_argv was already disabled by default in the recommended INI files (and will be default-disabled with PHP 8.5 even without an INI file). So I would expect this to be sufficiently rare overall. And nowadays I also expect most applications to touch $_SERVER one way or another during the execution (e.g. to retrieve request headers), so it will be initialized anyways.

Okay sure.
I can't double check whether the condition is right however, as I'm on vacation and don't have a development machine with me.

Note that these tests only fail with a primed opcache file cache (opcache.file_cache and opcache.validate_timestamps=0). Maybe this is related to recording/replaying, with the deprecation being emitted an additional time? (It's emitted twice in the failed test with the given configuration). I haven't checked yet, but I can take a look.

Maybe this is related to recording/replaying, with the deprecation being emitted an additional time?

Yes. The error message is recorded in OPcache, because the super-global JIT triggers the deprecation during compilation. With this change, the deprecation is triggered at SAPI start-up and will thus not be picked up by OPcache (and it's also arguably more correct to not trigger it at random stages during compilation, since it doesn't check what field of $_SERVER is accessed).