It's always struck me as pretty much useless; unless the service is uniquely identifying each downstream and somehow backing them off individually (which is not usually the case, you're usually backing off a consuming identity like an account or an address) then Retry-After is more or less meaning-free for an individual client.

In a practical sense, a 429 is just a 503. Back off and try again if you have time, otherwise fail. It's the passive-aggressive "I'm not providing service to your well-formed request, but it's you and not me" response code.

In my experience, servers often don't send 429 responses. Just last week I encountered an API that sent a 200 response with a body that read "Rate limit exceeded."

It's uncommon for user facing stuff, but only a little uncommon on the API side for abuse rate limiting. I know curl supports it.

This kind of code is useful anywhere you have message buses with finite resources, which is a lot broader than just HTTP. It lets you separate the how of data processing and transformation from the when. I keep a token bucket header in my personal toolbox for embedded work because it's just such a common and simple building block.