DBCC CHECKTABLE taking 15+ minutes to run on an empty table
I ended up opening an incident with Microsoft and it was determined that the sys.sysrscols (that can only be accessed via DAC) had over 200 million rows.  After they did a review it was found as part of DBCC SQL Server always does checks on system tables even for DBCC CHECKTABLE. From the DBCC CHECKTABLE manual:

Integrity checks are always performed on all system table indexes.

My understanding is sys.sysrscols does some column tracking and the reason for the large size is a number of tables (200+) we have that have 2,000+ partitions and 163 columns.  Almost all of them were temporary working tables that should have been dropped by the application but were not.  I cleared them out and the process returned to a normal response time for an empty table of less than 1 minute.
They also noted it is listed in the documentation that partitions can impact DBCC checks. From Partitioned Tables and Indexes:

DBCC Commands
With a larger number of partitions, DBCC commands could take longer to execute as the number of partitions increases.