Thanks! I've been mulling this over for weeks; nice to know it wasn't just staring me in the face...
So in conclusion, the lock avoids raising constraint violation errors in a few cases in READ COMMITTED mode. In REPEATABLE READ mode, it converts some constraint violation errors into serialization failures. Or at least that's how it looks to me.
Yeah, it had occurred to me that this is one place you might see some benefit. But waiting around on a potentially irrelevant update, just in case the RI violation resolves itself, didn't really sound like a net win. Not to mention the possibility of a deadlock, if the other transaction updates our PK or adds another reference to it.
