When designing our attestation proofs, we thought it was important to keep the records small enough to fit into the same number of storage slots that would be needed to store a single IPFS URI. We accomplished that by offloading much of the signature details to things that could be inferred, instead of including them in the payload itself; for example, by putting the name of the attester in the key name instead of the value, users can provide proofs from multiple authorities and consumers can easily check for proofs from signers they specifically trust. It also means the signer doesn’t need to be included in the payload itself, greatly shrinking the size.
In many off-chain realms, size is not a large constraint so the convention seems to be to include a lot of extra details to make sure consumers always have easy access to all the details they need for verification. But with blockchain engineering, conciseness is a constant goal, and I think it makes sense to keep things compact when stored as a record.
We chose CBOR for encoding the proof, which helps keep things compact and portable. It also makes the final proof deterministic, which has many benefits. Famously, bitcoin’s transaction malleability issue meant that a single transaction could have multiple valid transaction hashes, making it hard to track specific transactions that have been issued. Mt. Gox didn’t foresee that issue, and ended up losing so much money they collapsed.
I fear that using human-centric ASCII text and white space delimiters would not scale efficiently and would introduce too much variability for a system that relies on cryptographic proofs. Of course, I also am of the opinion that ENS text records should be considered on-chain data and therefore we shouldn’t expect them to be read directly by users, but instead interpreted by middleware which then displays the data in a user-friendly way.