There is a general principle that keys should be used for only one purpose. According to NIST's Key Usage guidelines (see section 5.2 on page 42),
In general, a single key should be used for only one purpose (e.g.,
encryption, authentication, key wrapping, random number generation, or
digital signatures). There are several reasons for this:
- The use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.
- Limiting the use of a key limits the damage that could be done if the key is compromised.
- Some uses of keys interfere with each other. For example, consider a key pair used for both key transport and digital signatures. In this
case, the private key is used as both a private key-transport key to
decrypt data-encryption keys and a private signature key to apply
digital signatures. It may be necessary to retain the private key-transport key
beyond the cryptoperiod of the corresponding public
key-transport key in order to decrypt the data-encryption keys needed
to access encrypted data. On the other hand, the private signature key
shall be destroyed at the expiration of its cryptoperiod to prevent
its compromise (see Section 5.3.6). In this example, the longevity
requirements for the private key-transport key and the private
digital-signature key contradict each other.
The same reasons that ordinary keys should have a single purpose also apply to a CA signing key or Subordinate CA (SCA) signing key.
I can't think of a specific vulnerability in certificates that reason #1 might create, but we've seen enough cryptographic vulnerabilities that have occurred whenever principles are violated, so I wouldn't completely discount it.
Regarding #2, you obviously want to limit the damage that could be done if a signing server is compromised. When you start running your own PKI, you realize how fragile the systems can be and how easy it can be to make subtle mistakes.
Reason #3 gets into system flexibility. For example, someone in property management may buy a pre-packaged security solution for building access control, and it may have its own requirements for SCA issuing certificates that don't match your current SCA certificate hierarchy. Rather than disrupting your other certificate issuing processes, you can isolate the change to just the impacted domain.
Of course, you can't just stack up subordinate CA certificates like building blocks. Every SCA link in the chain-of-trust means another certificate to be validated, and there are practical limits to how many certificates can be validated before the process becomes too burdensome on the clients. For that reason you'll see that Trusted Root CAs don't delegate to SCA certificates on their working servers, even if it would better segregate their infrastructure. But the trusted root CAs have a lot of experience in the field, and have designed their systems focused on the security of their architecture; we all trust them to do their jobs well. (The cynical reality is that whenever any root CA has made a mistake and been compromised in the past, the loss of trust means the company tends to go out of business quickly.)