Only large merchants are able to maintain such an infrastructure; (even
Coinbase recently failed at it, they forgot to update their
certificate). For end users that is completely unpractical.

Payment protocol is for when you buy stuff from purse.io, not really needed for face-to face transfers, end users, IMO.
 
The same benefit can be achieved without the complexity of BIP70, by
extending the Bitcoin URI scheme. The requestor is authenticated using
DNSSEC, and the payment request is signed using an EC private key. A
domain name and an EC signature are short enough to fit in a Bitcoin URI
and to be shared by QR code or SMS text.

 bitcoin:address?amount=xx&message=yyy&name=john.example.com&sig=zzz

I agree.  A TXT record at that name could contain the pubkey.  
 
That extension is sufficient to provide authenticated requests, without
requiring a https server. The signed data can be serialized from the
URI, and DNSSEC verification succeeds without requesting extra data from
the requestor. The only assumption is that the verifier is able to make
DNS requests.

The problem is that there's no way for a merchant to refuse a payment without a direct communication with the merchant's server.    Verify first / clear later is the rule.   Check stock, ensure you can deliver, and clear the payment on the way out the door.  

Also, as a merchant processing monthly subscriptions, you don't want the first time you hear about a user's payment to be after it hits the blockchain.  You could add a refund address to deal with it after the fact... stuff a refund address int OP_RETURN somehow?

bitcoin:address?amount=xx&currency=ccc&message=yyy&name=john.example.com&offset=3d&interval=1m&sig=zzz

... But what if the merchant simply goes out of business.  No OP_RETURN will help you here.   You'll be posting transactions into a dead wallet.  You could have some way of posting a "ping" transaction, and then monitoring for a valid response.   But this is "spamming the blockchain for communications".

No, I think BIP075 is fine.   You just need to extend the PaymentAck with a single field, instead of just having a memo.

next_payment_days : integer

The wallet, when it sees this field, re-initiates an invoice request after the selected number of days, after presenting the user with the content of the memo field which will presumably explain the subscription.   Wallet vendors can let users "auto approve" vendors as needed.

This is, I think, the absolute minimum needed to update BIP0070/0075 for subscriptions.