All right. I ran a test using an XEvent session to get the locks acquired by DBCC CHECK_IDENT with a RESEED. The important locks acquired are a SCH-M (Schema Modification) on the target table, an IX (intent Exclusive) on syscolpars, and an X (Exclusive) lock on a key in syscolpars. According to the lock compatability matrix found in BOL here, the SCH-M lock is incompatible with S(hared) locks so a read should block the reseed.

It was pretty easy to duplicate the issue just by having a long running query take a shared lock on the table.