The short answer:
If an intermediate is revoked it can no longer be used to verify certificates it was previously used to sign, rendering the children certificates invalid.
Exceptions apply for timestamped signatures.
Revocation of intermediate certificates:
There is no need for a different section for intermediate certificates.
The RFC shows a reference algorithm for certificate path building and verification.
Given a prospective certification path (a sequence of n certificates), path validation performs the following, per RFC 5280, section 6.1.3:
The basic path processing actions to be performed for certificate i
(for all i in [1..n]) are listed below.
(a) Verify the basic certificate information. The certificate
MUST satisfy each of the following:
(1) The signature on the certificate can be verified using
working_public_key_algorithm, the working_public_key, and
the working_public_key_parameters.
(2) The certificate validity period includes the current time.
(3) At the current time, the certificate is not revoked. This
may be determined by obtaining the appropriate CRL
(Section 6.3), by status information, or by out-of-band
mechanisms.
(4) The certificate issuer name is the working_issuer_name.
(3) specifically spells out certificate revocation in addition to certificate validity ((1) signature and (2) time).
This means that every certificate in the chain from trust anchor (aka root) to leaf certificate must not be revoked at the time of the check.
Revocation reason:
The reason field is mostly irrelevant, the only one that matters is removeFromCRL which removes a certificate from the CRL (basically "unrevoking" it). The final "certificate status" per section 6.3.3 is:
If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
then the revocation status has been determined, so return
cert_status.
Example:
Given the following simple path: root -> intermediate -> myexample.com.
If intermediate is found to be revoked in a CRL published by root, it will be considered invalid for all paths it is a part of. Since intermediate is invalid, I cannot verify the certificate for myexample.com, rendering it invalid it a well.
Answers to OP's take:
Depends on revocation reason code: it really doesn't. If a certificate was revoked, it can no longer be used to verify other certificates. It does not matter if the CA went out of business or leaked its private key.
there is a problem with issuing new CRLs: there isn't, the CRL revoking the intermediate CA is issued by its parent which is still valid. Since the intermediate CA is now revoked, the rest of the path is invalid.
But wait! Timestamped signatures
All of the above applies to path verification for "current" use. One notable exception is PKI use for timestamped signatures. This is described in RFC 3161.
Two important deviations from the above are spelled out in the RFC:
Use of revoked certificates, as long as the signature was prior to revocation: (from the intro)
... verify that a digital signature was
applied to a message before the corresponding certificate was revoked
thus allowing a revoked public key certificate to be used for
verifying signatures created prior to the time of revocation
Meaningful reason codes when a key has not been compromised. Details from section 4:
When a TSA shall not be used anymore, but the TSA private key has
not been compromised, the authority's certificate SHALL be
revoked. When the reasonCode extension relative to the revoked
certificate from the TSA is present in the CRL entry extensions,
it SHALL be set either to unspecified (0), affiliationChanged (3),
superseded (4) or cessationOfOperation (5). In that case, at any
future time, the tokens signed with the corresponding key will be
considered as invalid, but tokens generated before the revocation
time will remain valid.
