Any site that doesn't redirect to the SSL version (if applicable) will work. The benefit of using something like captive.apple.com is that it's specifically designed to NOT use SSL in order to trigger redirects and such, whereas something like example.com just so happens to not redirect to their SSL version, so it's (essentially) guaranteed to work vs example.com who could decide in the future to redirect to their SSL version if they want
If I regularly used that as a known-good site that should be up with no SSL, I'd trust that an apple-maintained site (backed by akamai) would be up before "example.com".
I'm sure there are plenty of others, but someone might remember that URL over another so I thought it would be helpful.
It's reserved for the purpose of documentation/illustrations (especially RFCs themselves) without fear of changes/invalid domains/directing mass traffic. It's also useful for establishing an idiom for those RFC examples.
example.com is maintained by IANA. It's an official example address for documentation purposes. So on one hand, it will survive even if Apple disappears, on the other, they're likely not expecting any significant traffic.
Using the site for captive portal access does not actually generate any traffic for the site, because the middlebox intercepts and rewrites the request. Traffic only occurs if there is no captive portal. Hence the easily parsed "Success" body of the Apple site.
Phones confirm whether you passed the captive portal by requesting the usual check url again. That means they'll still get one request after a successful login.
