Note that BIP 54 does not talk about transactions of 64 bytes, but rather proposes to forbid “Transactions whose witness-stripped serialized size is exactly 64 bytes”.

Still, perhaps I can alleviate you of some of your sadness: it seems very unlikely that anyone will come up with useful stripped transactions of 64-byte size.

Bitcoin transactions have to have at least one input, at least one output, and the header bytes. Without the witness data that leaves us with:

Usually 10 bytes, unless you have a lot of inputs or outputs.

In sum that’s at least 41 bytes, and that is for a transaction with an empty input script.

At least 9 bytes, even with an empty output script.

So, a transaction with an empty input script and an empty output script already puts you at 60 bytes, and that means that you’d have to distribute a total of four bytes into input script and/or output script to land at exactly 64 bytes.

The only standard types of transactions that I can think of that would be affected have a single native segwit input (who have empty input scripts), and either a single P2A output (which has a 4 byte output script) or an OP_RETURN output with a 2-byte payload. The former transaction would pay all its money to fees or make it up for grabs per an anyone-can-spend anchor. The latter would pay all its money to fees, or burn it per the OP_RETURN output. Neither seems seem useful to me, but either could evade the block by simply increasing the payload by one byte (e.g., introducing another standard pattern for P2A with three bytes, if it is used frequently). So, we would fix a consensus bug at potentially introducing a 1-byte penalty to a couple tx patterns that don’t seem useful at this time.