Well, come on. It's your responsibility as a client to check for fresh content in a manner that takes her posting patterns into account. It's not her responsibility as a server to provide content in a manner that takes her posting patterns into account.
Serious or not (sounded like sarcasm but one can never be too sure!), I'll elaborate on this point.
I think it's both parties' responsibility. Well, "responsibility" may be a strong word, but it depends what you want to achieve.
It's okay to return 429 if you receive more than one request per day. But if the goal is to not get those requests in the first place, you can make it way easier with that Cache-Control header.
A client might not support the Retry-After header; after all, it's not widely supported by web browsers, so I can see how some libraries might not even bother with adding that maintenance burden.
But Cache-Control is more widely supported, so it's more likely to be already implemented in client libraries (or even caching proxies).
If someone doesn't support Retry-After, and also ignores Cache-Control, by all means, return an error. It's probably a misconfiguration of their client library at best, or a broken client at worst.
I'm not saying one should bend backwards and put unrealistic effort into stuff like this; what I'm saying is, if the HTTP 429 thingy was an acceptable amount of effort, then the Cache-Control thing should be similar (actually way less) effort and time and should slightly reduce the amount of requests received.
