Makes sense if the Retry-After interval is also 6 hours.
But if you run your ACME client more often, i.e., every 2 to 4 hours, then you could use the header.
And I see the whole Retry-After being a "target" thing more as something like if $time > $retry-after then do_stuff else do_nothing. Not sure why you'd need to run the ACME client at exactly the target timestamp.
I think the main reason would be if the CA is trying to reduce (or spread out) load on their ARI-serving system. So if every client checked ARI at exactly midnight due to poor default schedules, having some way for the ARI server to tell the client to do their next check at some time, spread out, might be helpful? ARI is supposed to be easy for CAs to just offload to their CDN caches, but I could see wanting the specification to push clients toward following server recommendations just in case it turns out that servers are smarter about when they should be queried next than the clients are. Just a guess as to what might be the motivation.
The concern is the spec says to treat it as a target and be prompt at refreshing ARI info. Draft 7 is much different than Draft 3. To be a "good" client means we SHOULD do something. So, the question revolves around what this means in practice.
Draft 7
Note that in other HTTP applications, Retry-After often indicates the earliest time to retry a request. In this protocol, it indicates both the earliest time and a target time.
and
4.3.2. Client handling of Retry-After
After an initial fetch of a certificate's RenewalInfo, clients SHOULD
fetch it again as soon as possible after the time indicated in the
Retry-After header ...
Sure. But, you can see the changes in the draft I pointed out earlier. It went from specifically talking about what cron-based clients should do to saying only be driven by retry-after.
To be clear about my opinion ... even a cronjob running once or twice daily and checking ARI renewal window is far ahead of what we've had to date. ARI is a big improvement.
I think we'll need to wait for further clarification from the CA's as to best practice for cron-based clients though. And, of course the experience gained from the usual bruises and bandages from being at the leading edge
Currently in Certify The Web we set our own schedule for ARI checks (12 hrs) for our own convenience because we also check OCSP in the same batch, we will probably eventually use the server provided RetryAfter.
Keep in mind when accepting 3rd party suggestions that affect your own process that they may (for instance) inadvertently cause all certs to become due for renewal, which may exceed practical limits depending on scale.
We don't necessarily honor the Suggested Start/End of renewal if we would have renewed earlier than the suggested window, because ultimately the user, not the CA, controls that preference.
From the perspective of the ARI author, the ideal ACME client wakes up every hour, but only has to do local work most of the time: checking the latest ARI response to see if it's in the suggested window now, checking the latest retry-after to see if it needs to check again, checking the certs on disk to see if one has expired, checking the local config to see if there's a new cert to manage, etc. It only does "real" work if one of those checks says it needs to, so waking up that frequently is cheap.