Revocations are only an issue with key updates, which must be (and, in fact,
are) made on the basis of preferred keyserver URL's in self-signatures on keys.

With document signatures, the only important issue is to have the key retrieved
from somewhere, if it is not known to the verifier. I cannot see any way in
which an attacker can make things worse for anyone, if retrieval is attempted
from URL's in unhashed subpackets if the key is not available.

The application that I am working on is a pontentially very large archive of
signed documents (financial transaction authorizations) that also contains the
corresponding keys. The archive is supposed to be distributed/redundant, with
both the documents and the keys available from multiple servers and it can also
be migrated from one server to another. Servers can go online and offline all
the time, no address is permanent. It is trivially easy for a server to include
its own address into an unhashed subpacket and very useful, too. The server does
not have access to private keys.

Nothing needs to be explained to users if they can simply
gpg --verify document.asc
after retrieving it from the server. Much more needs to be explained if
instructions are necessary where to retrieve the corresponding public key.
Polluting the HKP/SKS infrastructure with all the keys (most of which are
disposable) that we use would impose an unfair burden on the infrastructure and
as such would be a very irresponsible thing to do.

How would not emitting an extra LF interfere with empty messages?
Has this decision been debated? If so, could you point me to the discussion?
Thank you in advance!

I respectfully disagree:
What you write is true for certification signatures, but not for document
signatures. Updates of keys should be driven by keyserver preference indications
on self-signatures on that key and those must obviously be hashed.
However, OpenPGP very cleverly allows for keyserver URLs in document signatures
and does take them into account. They are used for only one purpose: do download
the key if it is not known. In this case, unhashed subpackets are as good as
hashed ones (actually, better), because the cryptographic binding between the
signature and the public key can be verified anyway, there is no such thing as a
wrong source for the public key, if it does correspond to the signature.