Read the sentence before your quote: “There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181).” (Emphasis added.)
Also, you are asking your locally configured DNS resolver, not a deSEC NS. (Though in this case the result would be the same.)
Your suggestion might seem like a good suggestion for a recursive DNS resolver — if you ignore the “the name MUST NOT be an alias”.
However deSEC e.V. does not operate any (public) recursive DNS resolvers. It operates authoritative name servers.
In summary: I don’t think your suggestion makes sense.
Aside from the RFC violation of using a target with a CNAME, deSEC could return address records in the additional section if the target of the SRV record is configured properly, as is suggested but not required by the RFC. Such records are currently not returned, even when the target is in the same zone as the label with the SRV record. The suggestion is addressed to operators of authoritative nameservers, not just of recursive resolvers.
We use PowerDNS and Knot DNS as authoritative nameserver engines under the hood. Whether the SRV target addresses are returned or not is an implementation detail of these nameserver solutions. Although I don’t know the particular reasons for the decisions these vendors have made, I do think that they have thought about this, and made their choices for a reason. If you want to learn more, I suggest to reach out to their respective mailing lists.
In addition, as pointed out by others: Whether you’d actually see the additional record or not would depend on whether your resolver includes it in its response – and that in turn it can do even if it had to get it from a separately lookup. In other words, we can’t control resolver behavior anyway, and optimizing this on the resolver-authoritative path would have a really minor effect only.
