We were plagued by this issue several years ago (SQL2K5 publisher, remote distributor, 25 transactional subscribers in a 24/7 OLTP setup), and it was a real pain as the data set size meant reinitializing all the subscribers took well over 24 hours, along with all the associated customer service issues with out-of-date data.

I also was suspicious about using the "Continue on data consistency errors" agent profile. However we tried one subscriber with the profile, and on the next few PK violation incidents I made sure to follow the procedure mentioned by Wolfgang to check the replication transaction that was at fault. In all cases the the data had been successfully delivered by a previous replication transaction, so there was no data inconsistency. I also used Data Compare to check the table contents and it was absolutely in sync.

The issue appears to be a bug in replication.