This is not for "certificates above the end-entity" but for "root certificates" only.
In pure X.509, there is no such thing as a "root certificate". There are certificates, and there are trust anchors. A certificate contains a public key, the name of the entity that owns that key, and is signed by another entity (an "upper certification authority"). This process of signing must start somewhere, and that somewhere is a "trust anchor". A trust anchor is a name and a public key.
X.509 does not specify how any entity should encode trust anchors, since trust anchors are something that is known a priori, not something meant to be exchanged over the network. However, a traditional method of storing trust anchors is to use the same format as certificates. A certificate contains, among other things, a non-optional field for a signature from some upper CA. Instead of defining a new format for a trust anchor, Tradition is to fill the "signature field" with a self-signature. Thus is born a root certificate: a trust anchor that is encoded as a self-signed certificate.
But that self-signature is meaningless ! It has no security value whatsoever. Correspondingly, nobody verifies it(*). Therefore, there is no problem related to its use of a hash function that is otherwise regarded with some suspicion.
(*) Some systems heuristically check that signature because self-signed certificates can only be used as a root, not as anything else. But this is not a security feature; this is for user interface convenience, with no reliance on the safety of that signature. Hence, no problem with SHA-1 or, come what may, MD5 or MD2.