That means a plaintext of length 524 will be encrypted to a ciphertext of length 1024 and then will be sent. Isn't is also an inefficiency?
Not really; or at least, that's not an inefficiency we care about.
A length of 1024 means, in this context, 1024 bits (or 128 bytes). This compares favorably to RSA (for which a key with a 1024 bit ciphertext has questionable security). More importantly, a ciphertext of 1024 bits is fairly cheap to transport; it fits extremely easy in an IP packet (if we're communicating over IP); over wireless (which we tend to be sensitive to message length due to power reasons), it's still not too bad.
The reason we don't use McEliece now is the "expense"; that is, those parts of the cipher that make it costly to implement. And, the expensive part of McEliece is the public key (which is circa 200kbytes); we could fit it into a certificate, or pass it as an authenticated part of the key negotiation protocol, but it would be painful. Most everything else about McEliece (the ciphertext size, the computational effort) are things we can easily live with (with the possible exception of the private key; we don't have to worry about transporting that around, but we still need to store it securely).