How is it not rate limited? I don't understand why this is not a thing in every login activity everywhere. can someone explain one reason you might choose to NOT rate limit auth attempts? I don't understand :S
But the solution is pretty simple: rate limit to one attempt every few seconds, and if you want to lock the account, only do so after a lot of unsuccessful attempts. For example, bruteforcing is impractical if you can only try one password every five seconds, and essentially impossible if you only get 100 bites at the apple before you get locked out.
Honestly today i see very little reason to develope your own login mechanism and not use many of the available SSO's out there unless you are big enough for it to matter, and then you have no resource limitation.
The problem with rate limiting is that it's very hard to do it properly and scale it.
For example how do you do rate limiting? are you doing it per "session" e.g. increase the login proccessing time for each individual IP address? if so then distributed attacks will still be effective.
And if you are simply doing it for each sessions (by cookie or some other identifier) then it doesn't help against scripting attacks what so ever since they can be adapted to request a new session every time.
Where do you set the limit flag? is it handled by the authentication front end? If so you'll have issues enforcing this if you have a distributed solution which a service with as many users as iCloud will have.
If you are doing it on your main identity DB then you also might have scalability issues since you will have to sync these values accross all of your instances.
Also don't forget that every time you do this "rate limit" it means that there will be a "proccess" on your authentication server idling for the duration of the limit, this means that there will be halted login attempts on your authentication servers, enough of them and you might get into some serious resource issues.
A 10 second pause might be acceptable on your laptop after you type your password wrong 3 times, but doing it on the server means that it allocates resources then puts limitations on how fast these resources can be cleared which isn't a very good design.
As for the UX issues the problem is that it's not always as simple as some username and password, especially for services such as iCloud where a simple missbihaving app can cause accounts to be effectively locked out, and when you count in the amount of users such services has then it becomes quite a frequent event.
So yes while i do agree rate limiting does effectively prevent brute forcing, i don't see it as being a viable strategy for an online service. Rate limiting should be left for closed enviornments where you have full control over your clients and where users can be serviced in a reasonable manner.
Putting it on distributed open services that service millions of users where you might have various types of clients that you have no control over making authentication requests will just cause trouble.
On the contrary, I see very little reason to use someone else's authentication infrastructure (Facebook, Google+, et al) without at least also providing the option to register using plain old email, unless you're developing an app that is intimately tied to that service. You lose so much control over your users, and you risk everything on your SSO provider not changing their minds about how you can use their service (see Twitter.)
Regarding your other points about rate limiting, I think you're overcomplicating the situation. It doesn't require a process on your authentication server that sits around and waits for one particular client to be allowed to try again (why would it?), and db sync issues are largely irrelevant unless you're at serious scale, which 99.9999% of web apps never will be, and if they are at serious scale, chances are syncing a "last_login_attempt" field in a login table is the least of their difficulties.
In Apple's case, of course rate limiting isn't the only solution they should be using, but it's a perfectly fine solution in the vast majority of cases where building a heuristic engine to protect a cat forum login page is overkill.
Nothing is, or should be, beyond the scope of Apple.