We have many routers at work.
Almost all of them have 10K interfaces on each one.
Creating dashboards which present many different views of many different, large routers can create undue database load. (We're actively discouraging their use as a long-running process because each dashboard widget gets its own database connection, not a shared database connection.) We will kill all long running queries in the database if they run longer than 30 minutes.
The database schema design makes interesting trade-off decisions (optimizing for ease of write at the expense of complex / cross-device reads).
The new GraphQL schema model looks promising, but we're still waiting for that to begin to appear in the SL1 core functionality.
Given enough hardware and budget, you can go a long ways before you start pushing the boundaries of the platform architecture.
Being conservative in what you monitor for the vast majority of your CIs allows you to retain compute capacity for dashboards, runbook engines and the like.
Having large routers or vCenters will require an upscaling of your data collector sizings just to complete the Device Component Map data collection.