I think earlier in this thread there was a link to the original discussion about this and ultimately it came down to the fact that reverse DNS zone delegations are historically very poorly managed and often out of date. That is to say, controlling the reverse lookup zone for an IP range does not necessarily prove control of the associated IP addresses in that range. Whereas with a forward lookup name, control of the zone is control of the names in that zone.
There are also probably worries about the reverse problem when you don't control your own reverse zone, but your upstream network provider does. They would then be able to generate certificates on your behalf without your knowledge (or at least until you get a CT notification that it happened).
ACME does support this, but we may initially launch IP address certificates as "IP only". We haven't made final decisions here yet. Feedback is welcome.
It is easier to add more features later than to remove them, so we are going to try to launch fairly minimally here.
For what it's worth, the public DNS-over-HTTPS certs I've checked (Cloudflare, Google, OpenDNS, Quad9) all combine IPs with hostnames, and the first three include a wildcard hostname as well in there. So there's clearly some demand for combined certs, though I don't know as those services are representative of the kinds of requests people are hoping Let's Encrypt will provide.
I think there's some usefulness to mix DNS and IP identifiers in a cert. The reason being that various TLS libraries tend to include SNI only if a hostname was given during connect. So if someone connects directly via IP, there's not going to be any SNI extension, which can be confused with an implementation that doesn't support SNI at all, but has connected via hostname. (The browsers all do SNI, even ancient ones, but I envision use cases like DoT for IP certs, where the S/W landscape is quite different). So a cert that catches both a "no SNI fallback, or direct IP" sounds useful.
Also the DoT servers may not all have great capabilities regarding multiple certificate support (again, no well-written HTTPS server at play), so maybe the stunnel or whatever you're using can only handle one cert. But then you might want your DoT to be reachable both via hostname (for clients that can do DoT bootstrapping) or direct IP (for clients that can't), which again means a dual-cert is quite useful.
Probably a lot because very soon "short-lived" certs must not be valid for more than 7 days.
Adhering to these specs means no need for CA revocation, CRL, or OCSP.
constrained to an initial maximum validity period of ten (10) days. The proposal stipulates that short-lived certificates issued on or after 15 March 2026 must not have a Validity Period greater than seven (7) days.