In fact it's much more than that, the CA is not supposed to sign any certificate it didn't choose - and it isn't meaningful in X.509 to have more than one signature.
You will often see people describing the sequence of events something like "I send them this CSR and then the CA signs it" but that's not really what happens at all. The CA is obliged to construct a to-be-signed-Certificate (tbsCertificate) of their own choosing, incorporating only information they're actually happy to stand behind, and with a largely random serial number at the start.
The serial number is because X.509 doesn't have a nonce component, serial numbers are very near the start of the document so it would likely be impossible (using known techniques) to collide a certificate hash (even a known broken one like MD5) so long as this number is very random and chosen by the CA not the subscriber.
The constraint on information in the certificate (e.g. Subject information) is because the CA is signing the entire document. Relying Parties have no reason to assume that a certificate for "Johnny Poopy Pants" was actually not issued based on the CA believing this is really "Johnny Poopy Pants" but instead just because it also mentions the DNS name some.cheap-server.example and the subscriber does control some.cheap-server.example. So, any claims of information about the Subject that aren't being warranted by the CA are not included in the certificate. You can send Let's Encrypt a CSR saying your company name, email address, mailing address of the head office, a logo, whatever, it just gets ignored and Let's Encrypt only care about the DNS names you asked for, those are all that will be in the certificate.
I don't think X.509 has a way to express multiple signatures on the same certificate. Issuer name, etc, are limited to one per certificate. See also tialaramex's excellent sibling comment about CAs constructing a new cert to sign including a new serial number.
Cross signed roots work by offering multiple certificates for the same key: you can use a self-signed root (from your trust store) or an intermediate signed by a different issuer, or if your validating stack is really competent, you can send multiple intermediates and the validator will check if any of them chain to an acceptable root.
But, the leaf (or end-entity) cert MUST be the first certificate sent, and only one certificate can be first, so there's no optionality there.
If CAs would be willing to sign limited scope intermediates (and if limited scope intermediates were widely usable), you could get your intermediate widely signed and have your leaf certificate signed by that, and include multiple chains from your intermediate. But that would take you from two certs (leaf + CA intermediate) to one + 2N certs (leaf + (your intermediate signed by CA + CA intermediate) * each CA) and all of that would add up to increase the handshake size and slow down initial communication.
It might be nice in some situations, but it's also costly, and support is iffy if you stray outside browsers.
