SSL termination can be performed on a machine different from the one running the web server. Even if it is done on the same machine, web applications are typically run with limited permissions, so they can't access SSL private key.
This is obvious. If you have separate machines you can of course run payment request signing on them as well, and have that machine do some basic sanity checks to avoid signing obviously bogus requests (ie, to addresses that are not owned by the merchant). Same thing for compartmentalizing using separate user accounts, SELinux, trusted computing, etc.
The "compromised web server" scenario applies for small merchants where everything is done on one machine for cost reasons, which today describes most Bitcoin accepting merchants.
Secondly, this protocol can't be used securely with offline wallet because Payment structure is not signed so it can be modified by compromised customer's online computer.
The transactions themselves can't be modified. I suppose one of the tx keys could be used to sign the refund_to attribute as well, but I doubt any virus would make a profit by maliciously modifying the refund address. Refunds shouldn't be that common. It's a simple extension to sign the rest of Payment with a key used in the transactions though. Gavin can make the call.
Also, it doesn't depend on traditional PKI. Merchants may sign their master keys with SSL certificates, GPG certificates, or even both. So a normal customer can verify merchant's key using SSL certificate, but a paranoid customer, who doesn't trust governments and CAs but trusts GPG WOT, can verify the merchant's key using GPG.
As certs just encode public keys anyway, nothing stops you from directly importing certificates into a local trust store and deciding you trust them because of a WoT instead of a chain to a root CA. In practice basically no-one uses the web of trust. So this mode of operation isn't a big deal, but it can be done if you want it.