Nominally, in pure "X.509" philosophy, the SSL client should obtain the server's certificate and all needed intermediate CA certificates in any way it sees fit, but in particular by talking to the Directory, which is the giant worldwide LDAP server which contains everything.
Unfortunately, the Directory never existed (too centralized, too complex) so practical protocols have to include some provision for sending certificates themselves. It so happens in SSL/TLS: the server sends its own certificate and a bunch of other certificates which "may help" the client. In fact, the TLS standard even specifies that the server MUST send a ready-to-validate chain:
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
In particular, notice that the self-signed root itself may or may not be included. This root is never needed client side (and never has been) but sending it is "traditional" (one of the myriads of traditions in IT; not useful, but mostly harmless).
The client should be able to validate the certificate chain "as is" and is allowed (as in "morally justified"), per the TLS standard, to reject the handshake if the exact chain sent by the server cannot be validated. However, the client is also allowed (and encouraged) to try to rebuild some other chain and validate that, if what the server sent was not directly usable. Modern browsers do that; they will try to use locally known intermediate CA certificates (obtained at installation, or cached), and may also download extra CA certificates, following URL found in the certificates themselves (
Authority Information Access extension). At least IE on (recent) Windows will do that, but, to avoid a nasty chicken-and-egg situation, it will follow only
http:// URL, not
https://. These extra downloads can take some time and make the handshake less robust, in case of flaky network or timeout.
Summary: sending the root is not mandatory, but traditional (the +1 kB network overhead per full handshake is unlikely to have any significant or even detectable impact on performance). Sending the intermediate CA is nominally required, and, in practice, recommended, although modern browsers/OS may recover by using alternate certificate chain building strategies.