DBCC checkdb showing failure after a restore
Should I attempt to restore the database again or proceed with attempting to repair? I only hesitate because it is a rather large DB and restoring takes quite a while.


I'd probably do both, but restore it to a new name.  


  All of the table errors are related to a single table I could just drop and recreate. However I don't understand what the IAM error really means or its impact.


If the data in that table really, truly doesn't matter, and you can really, truly drop and recreate the table, that's probably the fastest option.  Especially since "repair_allow_data_loss" will probably cause data loss, yes.  

As for what the IAM error means:

Short version:  Your table innards are corrupted.

Longer version:  The Index Allocation Map tells SQL Server where to get the actual objects.  In this case, based on the references to RIDs I'm guessing this is a table without a clustered index (in other words, a heap), and that it's telling SQL where to get the data that was actively updated inside the heap.  (One of the things that happens when a heap has updates is that if the new information doesn't fit in the old space, a pointer is created that tells SQL where to get the new information.)

Here's an article on IAM pages, and here's a good video on heaps in SQL Server that came up when I was looking for IAM info for you.