The hostname is included in the initial SSL handshake to support servers which have multiple host names (with different certificates) on the same IP address (SNI: Server Name Indication). This is similar to the Host-header in plain HTTP requests. The name is included in the first message from the client (ClientHello), that is before any identification and key exchange is done, so that the server can offer the correct certificate for identification.
While encrypting the hostname would be nice, the question would be which key to use for encryption. The key exchange comes only after identification of the site by certificate, because otherwise you might exchange keys with a man-in-the-middle. But identification with certificates already needs the hostname so that the server can offer the matching certificate. So the encryption of the hostname would need to be done with a key either based on some other kind of identification or in a way not safe against man-in-the-middle.
There could be ways to protect the hostname in the SSL handshake, but at the cost of additional overhead in handshake and infrastructure. There are ongoing discussion if and how to include encrypted SNI into TLS 1.3. I suggest you have a look at this presentation and the IETF TLS mailing list.
Apart from that, leakage of the hostname can also occur by other means, like the preceding DNS lookup for the name. And of course the certificate sent in the servers response is not encrypted too (same problem, no key yet) and thus one can extract the requested target from the servers response.
There are a lots of sites out there which will not work without SNI, like all of Cloudflares free SSL offer. If accessed by a client not supporting SNI (like IE8 on Windows XP) this will result in either the wrong certificate served or some SSL handshake error like 'unknown_name'.