The reason why someone suggested the idea was to “fix” the problem of Bitcoin users not paying attention to the payment ID field and making deposits the recipient cannot match, if I remember correctly. (Didn’t find the original post or the source of the idea, so it might not be correct.)
That was only part of the reason. The other reason is that the crypto ecosystem generally operates on the concept of address = destination. In addition to the use case of exchanges, payment processors generate an address for an invoice. When you pay to that address, the payment is applied to the invoice.
Payment IDs exist in cryptonote because of the cost of scanning for stealth address payments. Separating the destination into two parts ("address" and "payment ID") is simply an optimization to allow faster scanning of a large group of destinations, but that really isn't something that users need to be concerned with. (Payment IDs weren't even part of the original design, but were added later, after the Bytecoin "reveal" i.e. launch, most likely when their exchange identified the problem by trying to actually process payments without it.)
What responsible wallets could also do, to educate users about the “reference field” (payment IDs), is to prompt the user if they really want to leave the payment ID field empty. That way the users at least confirm that they know what they’re doing if they transfer money with an empty payment id.
I disagree. I don't want to be bugged when I make ordinary payments. I rarely use exchanges and there are no (?) payment processors in the Monero space. Payment ID, blank or otherwise, is almost completely uninteresting to me, and I don't want to be prompted to enter one.
Serialized and stealth payment IDs are already on the development goals document and have been for several months. It's something that is going to happen. The only real questions revolve around how to implement it. Once it is implemented there is little doubt it will be adopted by payees because of the vastly reduced support costs associated with explaining the separate payment ID concept to users who don't really care about it, and dealing with failures when that doesn't happen properly.
Stealth payment IDs are fine, and good for the case where payment IDs aren't assigned in a proper one-time use manner (the same issue solved by regular stealth addresses preventing Bitcoin's rampant, but in-theory unnecessary, address reuse). And indeed they can be encoded smaller (hex is dumb compared to base 58). But even if they are little shorter, Monero addresses(+pid) will still be extremely long (too long to memorize, and too long to be a drop-in replacement for BTC addresses), so I don't see much of a benefit there from the shorter length itself, in practice.
we would soon get users who would want to pay to several of those addresses, but since this is technically not possible we will forbid that
This is an artifact of the how payment IDs were tacked onto the system at the last minute (after release in fact). There is no reason why a payment ID shouldn't be (optionally) attached to each destination, not the transaction itself. Failing that, any wallet presented with an attempt to send to multiple payment IDs can break up the transaction, just as they do now for transactions that are too large.
