You may have a terminology or other understanding problem with the term “primary key” as identified in Phil w's response. Skipping over that to the operations being taken on rows:
Is updating a table by delete+insert better than <anything>
As well as performance issues caused by taking multiple actions against the same row, and other resource issues slightly further down the line if you are using log based backups, replication, etc., delete-then-insert can lead to unexpected data loss or corruption.
If any foreign keys have been defined with
ON CASCADE DELETE child data will be silently deleted too, and not brought back when you re-insert the row. This is true even if both are done within a single explicit transaction: the DB will not wait to see if the PK value reappears before taking the cascaded delete action. This could lead to further deletes in even more tables if the cascaded delete causes further cascades due to more FKs defined this way.
Similarly, triggers can cause data loss, and might also cause other logical corruption (as they can do other than simply delete) or unintended actions (due to the changes they make in other data being reacted to by other parts of your applications).
Of course delete+insert is safe if no such actions are defined, but you don't know that they will never be added later. Or you might later want to add them for some something, but not be able to because existing code that you don't have time to change relies on them not being present. It might be fine forever for this particular DB+code, but I would get into the habit of avoiding such methods ASAP so you don't have to unlearn the habit of using them at a later time.
As far as is possible/practical, keep your code doing literally what it is doing functionally: an update to a row should be an update¹, not a delete followed by an insert. This has the added advantage of making your code clearer to anyone² else looking at it.
 well, to be more complete, merge and upsert operations are updates for those rows too, if your DB supports such constructs, as they are really syntactic sugar around the insert/update/delete primitive operations.
 where “anyone” could be future you who barely remembers writing the ocde e has been asked to make alterations