I'm not sure how applicable this scenario is. Any CA incident that involves the CA/browser forum already requires a list of affected certificates to be made public. During past incidents (i.e. those predating ARI) Let's Encrypt has commonly made lists (often CSV files) available for all affected serials and/or crt.sh ids, like in this incident. The scenario you describe can only apply if an incident occurs that does not involve the CAB and where a legitimate interest exists in keeping this information undisclosed.
In general, probing for vulnerabilities can always be done some way or another. In your hypothetical example, I could just assume that all certificates use weak keys and try to bruteforce them. Thus, I would be able to figure this out no matter if affected certs are public or not. Note that this always assumes that you're targeting specific sites, because a full bruteforce of all serials is always infeasible.
You can also argue that having serials fully public (i.e. not only being able to probe a given site via ARI, but actually having the full list of affected certs) is useful in many cases. For example, during the above linked incident I actually contacted site owners I knew were affected but hadn't renewed yet. This was only feasible because I could search the list of affected certificates by FQDN, so I could scan that for domains I knew.