More from inside the walls:

Q: Does anyone know why we’ve created two ways to sign the components? The certificate form covers all the needs I can see. I wonder why we have a separate “strong naming” manner to do signing that doesn’t cover all the security issues. It seems like both could easily be covered by using the private key from the certificate. Am I missing something?

A: (from the Security PM on the CLR team)
Strong names were originally designed for use by our loader to

a) establish assembly integrity (bits haven’t changed since last signing) b) to enable a cryptographically strong assembly identity for following assembly references.

It is true that the key pair of a cert could have been used for this as well, however, we did not think it appropriate to have to require every developer for the .net framework to own their own certificates. Furthermore, if the same development shop wishes to create multiple publisher identities, they might have needed to get multiple certificates.  Also strong names are more light weight – no revocation checks are performed, there is no trust UI popped to the user by virtue of an executable just being signed by a strong name.