That was a conscious decision to distribute the load for the hosting of the Status List. It is a SHOULD in the draft, so implementations may choose to not use the time of fetching + ttl, but use iat + ttl to guarantee most up-to-date information. The Status List Token can be considered valid until it hits exp time and it should imho be up to the RP policy how to use ttl.

Thanks for confirming this was a conscious decision. That is currently not very clear from the draft itself. I agree that in general that would make a sensible default.
There will be ecosystems with different needs for their stakeholders, depending on among others: the number of stakeholders, their size, their roles, timings, regulations, status list batch parameters and infrastructure.

Could I suggest alternatively to include a subsection under "implementation considerations"?
Basically the section should point out that setting the frequency for ttl for Issuers is balancing operational load (costs) with timeliness of propagating status changes to the ecosystem. And choices for exp and ttl at the same time influence availability of using tokens for End-Users at Relying Parties.
For Relying Parties the consideration would be similar, timeliness of status information versus putting a burden on, with risk of overloading, the Issuer's infrastructure (unintentional DDoS). Using the time of fetching as baseline or adding some random delay on top of iat+ttl are common methods to avoid unintentionally DDoS-ing an Issuer's infrastructure.
It is up to applications and deployments of the status list specification to weigh the various parameters mentioned above into their implementation decision.