You trust whatever server you query. That might be server one, or it might be server one and server two. It's a federated network, so you make requests through your own server.
> And will XMPP server 2 have my IP address?
No. It's a federated network, like email, so it just gets your XMPP address (historically referred to as a "Jabber ID" or "JID").
XMPP is not e2ee, the second server gets your JID (but not your IP, supposing your client doesn't leak it): you need to trust the servers (1, 2 and the resolver).
Also; you don't get virtual circuits, but the performance should be superior. Tor only supports A, AAAA and PTR; DoX supports every record type.
You can connect to XMPP servers over tor, even host them on .onion addresses.
Also, XMPP has e2e extensions, at least one of which supports encrypting/verifying arbitrary XML[1], so if the resolver supported it, you could only trust the resolver. (also don't forget about DNSSEC which can be used to verify DNS responses too)
There's an awful lot of "why not?" here. Remember, this is an Experimental XEP. The XMPP Council saw no reason to actively block it, but that doesn't mean we're all mad keen that everyone should rush out and do it.
There was an intense debate on whether it ought to be published as Standards Track or Humorous...
I'm sure there are valid reasons, but I also think there's a law that no matter how comprehensive your application protocol, it will eventually get turned into a transport for a higher-level (sometimes shoddier) application protocol.
1. performance: since the TCP+TLS handshake is only performed once and the connection is kept open forever
2. privacy: the resolver doesn't get the requesting party's IP address