On platforms that compile policy-maps into TCAM entries, there will be pre-defined limits on how many different policy-maps can be applied to interfaces. This limit comes from the static "carving" of TCAM resources into different regions for different usages: FIB, ACL, QoS, etc. The different regions are not dynamically fungible in that, for example, unused FIB entries cannot be used for QoS purposes. Some systems support re-carving the TCAM to optimize for different use-cases by allowing particular resource "profiles" to be configured, but this usually requires a reboot to take effect.
Platforms that forward in software (ie, CPU-based forwarding) typically do not use TCAMs for FIB/ACL/QoS/etc lookups and so the number of class-maps & policy-maps need only be limited by RAM size. Platforms with ASIC/NPU forwarding often use TCAMs and have these hardware limits. It should be noted that even in ASIC/NPU platforms, usually class-maps and policy-maps occupy only RAM until they are actually applied to an interface with a service-policy command, and so the number of such maps should be limited only by RAM until then. It is at the time of interface application of the service policies that, typically, the QoS config is compiled into actual TCAM entries.
Disclaimer: I am long in CSCO
