SirArthur has a good point about the normal online merchant case, which is what the send-by-IP option is more suited to. This is the case where the merchant will have a server on a static IP and their own domain name and SSL cert.
Instead of connecting by IP, we can connect to a domain name by SSL, using the existing CA infrastructure to authenticate that you're connected to the owner of that domain.
The user would send to domain.com (or www.domain.com is ok too). That would be very natural and users could see and verify that what they entered is who they intend to pay.
The SSL also makes it safe for TOR users.
Problem is, I think merchants would still prefer to use bitcoin addresses to be certain they know what the payment is for. You simply cannot count on users to enter the right thing in the comment fields to identify the transaction. It would only approach practical if we had a mailto style link that prepopulates the comment field with the order number, but then the link could just as well be a bitcoin address.
Just having an open bitcoin server at domain.com that users could send unidentified payments to would be too much of a liability. Regular users aren't used to the idea of having to identify the payment. Merchants would get too many blank payments followed by "I paid you, where's my stuff?!" a week later.
The payment sequence does have a step where the receiver verifies the order before accepting it. It can reject the payment and return an error message if it doesn't contain a valid order number. That would require a difficult level of integration of custom code with the bitcoin server though.