I think I remember when this was added and I was strongly against it since I don't think HTTPS should ever be relied on.
This BIP describes payment protocol messages encoded using Google's Protocol Buffers, authenticated using X.509 certificates, and communicated over http/https. Future BIPs might extend this payment protocol to other encodings, PKI systems, or transport protocols.
Everything in the above quote is utterly wrong and against my philosophy.
In my opinion, such messages should be exclusively deliver over the Bitcoin's own network, signed by the private keys of the sender's bitcoins, and perhaps encrypted using the message receiver's public key (PGP over Bitcoin). Is it technically possible? I don't know, but it should be, since Bitcoin utilizes PKI and PGP is based on that.
I agree that all of the messages should be signed by the message sender's private key to ensure that the message isn't modified between the consumer and the merchant. E.g. the request from the merchant is signed by one of the addresses in the output section, the payment from the consumer is signed with one of the addresses used in the payment transaction, and the paymentACK from the merchant is signed with the same key as the first message.
Regarding the http/https, I think that was a good choice since that is an existing protocol which provides some privacy and direct connection between two computers instead of flooding the network like transactions do. Although the choice of X.509 certificates for signing is questionable, I can also understand that because those have names associated with them.
Perhaps you (or maybe I, if I have enough time) can write some code to add such things to the payment protocol and submit at PR.