Basically: if apple.com is down, all the ios devices go down...
Apple just fell quite a few points for me.
I'd be more interested in learning how iOS reacts when TCP (HTTP) connections to that URL time out, or are treated as a closed port.
I guess if you're a large corporate and you don't want iPads/iPhones using your wifi, this is an absolutely great way to block them with zero effort!
For what it's worth, recent copies of Android try to help you through the captive portal process as well, though I doubt they fail if android/google.com go down. (Though, Android has always had an indicator, they only become colored after Gapps makes a good connection to Google)
Besides the fact that it's terribly fragile (as seen here), but if it's really an anti-imposter measure, it's a pretty awful one. (Okay, we'll just MITM every non-apple.com URL).
A great many wifi networks are open to the public, but redirect all HTTP requests to a login page. Think airports, coffee shops, hotels, etc. This is called a "captive" network. The apple.com request here is a heuristic to detect the "captive" network, so it can show a web browser inline that shows you the redirected URL so you can log in. This is actually a really nice feature when you're on a captive network.
If the page times out, I don't know what happens. But this time, the page explicitly responded with a 404, which it "should never do", so the device successfully detected a "MITM" and did the right thing. (Except in this case, apple.com webmasters screwed up)
When did "successful wifi connection" mean having access to this unstable apple.com url?
Remember Apple never optimises for edge case.