I think the one thing you're missing, that makes this all almost make sense, is the concept of an "Authorization Domain Name" (ADN). The BRs define this as:
Authorization Domain Name : The FQDN used to obtain authorization for a given FQDN to be included in a Certificate. [...] The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation.
That's a big definition, and also a really bad one (we're working on a whole ballot to fix it), but it gets the main idea across: for certain validation methods (of which dns-01 and dns-persist-01 are included), the CA may select any parent domain as the ADN and choose to perform validation at that ADN instead of at the requested FQDN.
This definition exists because it is useful for big CAs and big corporations to be able to negotiate an ADN at which all validation will occur. You want to get certificates for ten thousand doubly-nested subdomains of example.com? Contact CACorp and have your rep put a note on your account saying that all validations should be done at example.com itself, rather than on each individual subdomain. This works great for corporations and CAs that have support staff who can arrange such things.
The problem is that ACME hasn't historically had a mechanism to negotiate an ADN. RFC 8555 says that ACME clients should put the dns-01 record directly at the name they're requesting, so that's what all ACME clients have done, and that's the only place ACME servers have checked. This new method is opening up a new world of possibilities, and the ACME protocol may need to adapt to support it. In fact, I filed a bug about this against the dns-persist-01 Internet Draft over a month ago, but there hasn't been motion on it yet.
All of that is a long way to say you're asking very good questions, and we don't fully know the answer yet 