There have already been plenty of good answers to this that pretty much boil down to "Depends on the circumstance", and I can't add anything to those.
One thing that hasn't been mentioned, however, that I think needs to be mentioned, is that you should never ever reuse primary keys that have been generated by a sequence or an AUTO_INCREMENT system.
When you delete an item that had been assigned a primary key by such a system there will be gaps in the primary key column, left by the deleted data. There is a great temptation to reassign those gaps to new items as they're added, or even worse, to shuffle the existing data to give it a new ID to remove the gaps, but doing so will give rise to issues that you'd never have to deal with if you just left the keys alone.
Say you're keeping a database of printers for managing reordering consumables. Printer 13, an old laser printer, breaks down beyond economic repair so you throw it out. Meanwhile, for an unrelated reason, someone orders a new thermal printer for doing barcode printing in the warehouse, and that printer happens to arrive before the replacement for printer 13. The administrator logs that new printer into the database and, because 13 is now free and you're recycling IDs, the new thermal printer gets allocated 13 as its ID.
Now someone tells you that printer 13 is almost out of ink. You remember that printer 13 is a laser printer so you don't bother looking it up in the database, and you place an order for a toner cartridge. Only you actually needed to order a thermal ink pack because printer 13 isn't a laser printer anymore. When the toner cartridge arrives you can't use it because it's the wrong ink refill for the printer, you can't print out any more bar codes and you can't ship any orders waiting to be dispatched.
Even worse, what happens if you delete printer 13 and shuffle all the printers that come after it down to fill the gap? Printer 14 (some decrepit old dot matrix) becomes printer 13, printer 15 becomes printer 14 and so on.
All the printers have labels on them so they can be cross-referenced with the database, but now all the labels are out of date. You'll have to go round, locate every printer in the business (which could run into hundreds!) and relabel them. That's hardly an effective use of time. And it's also an error-prone process, and what happens if it just never gets done? Someone calls in to say printer 14 has broken down and needs fixing urgently, so you look it up and find that printer 14 is an inkjet printer in Reception. Only because you've shuffled the IDs around, it's actually the dot matrix printer that needs fixing urgently. The guy who called in the problem is left hanging, whilst the receptionist has a tech support guy she never called for turn up to fix a printer which wasn't broken.
You should think of IDs assigned by an auto-increment system as permanent, they're immutable and can't be reused, even if the thing that the ID refers to ceases to exist. Some people claim that they don't want to have to worry about IDs running out, but even with 32 bit systems and signed IDs, there's still 2 billion or so IDs available. If you can make the ID column unsigned then this doubles to 4 billion, and on 64 bit systems the number of available IDs is literally greater than the number of stars in the sky. You're not going to run out of IDs.