The subject name, in a certificate, is in the
subjectDN field, which is a Distinguished Name: a structure name whose initial goal was to serve as index in the Directory hierarchy (the Directory never existed in practice, but it can be imagined as a giant worldwide LDAP server).
Sometimes, there are some usages which call for notions of identity that do not map well (or at all) to the format of a DN. For instance, if a certificate is to be used for S/MIME, then it is desirable to encode email addresses in certificates, and the standard way to do that is through a Subject Alt Name extension.
As a rule, what matters is what applications will do. You can put a Subject Alt Name extension with arbitrary contents in a CA certificate. However, it is mostly useless since CA certificates are meant to be processed by applications who validate certificate chains -- these applications will ignore the SAN extension in a CA certificate. To put things briefly: the notion of identity used by CA certificates is the one needed for building and validating certificate chains, and that uses the DN (from the
issuerDN fields). Thus, SAN extensions are not useful for CA certificates.
(Well, mostly. Theoretically, you could use Name Constraints extensions that apply restrictions on subsequent certificates in the chain, including CA certificates, and these constraints take the SAN into consideration. However, Name Constraints, though standard, suffer from lack of support from usual libraries, so in practice nobody uses them.)
(Still theoretically, it is allowed by standards to have an empty
subjectDN, in which case a SAN extension must be present and contain a name of type
directoryName, i.e. a DN, and that DN will then be used as if it had been found in the
subjectDN field. The purpose of this specific point is unclear; I guess it was included to appease the aesthetic sense of some committee member, somewhere.)