The premise (of authentication) is that the identity of the policy host is the same as the identity of the @domain.
That is, if mail is sent to you@example.com, the certificate presented by whatever host is serving the policy must be valid for example.com.
So even if the TXT record functioned as you describe, mta-sts.example2.com would have to have a cert valid for example.com. Of course it could provide a single cert with SANs valid for all example*.coms that you run, but such a setup would preclude using SNI to serve the "correct" cert.
tl;dr: fetchers have to talk to "example.com" so that the HTTPS server knows what cert to present, and the cert has to match "example.com" so senders know the host is actually authenticated.
Regarding your comment on reverse proxies, it's actually quite easy to setup an HTTPS server that proxies some hosting org's policy but uses Let's Encrypt to fetch the proper cert for your domain. I did this for mine in about 50 lines of Go. Not saying I'd trust this for some production setup, but it's really quite easy. :)
I know someone will say "Just use S3 it's easy" but doing 15 times is an annoyance, it feels like an obviously missing feature to allow consolidation.
Edit: Section 8.2 describes using a CNAME to achieve this effect. But it also involves running reverse proxies and similar efforts.