Isn't it a threat that anyone can see my secure website?
TLS was designed to protect the application payload. It was not designed to protect the meta information of the connection, i.e. the domain name, source and target IP address, number of bytes transmitted, timing of traffic etc. There can definitely be a privacy risk when somebody is getting these information, but to protect the privacy was not a design goal of TLS. The goal was instead to protect the application data against sniffing and manipulation.
The target domain name in the ClientHello (i.e. SNI) is needed by the server to find out which certificate to provide in the case the multiple domains and certificates are provided on the same IP address. It is similar to the Host header of HTTP, only that it is available before the encryption starts so that the proper certificate can be provided inside the TLS handshake.
The domain name is not only visible in the ClientHello. Until TLS 1.2 the certificates (containing the domain name as subject or subject alternative names) where also sent by the server in clear - this was changed with TLS 1.3. There is also a way to encrypt SNI - ESNI is supported by several clients and servers already. But the same information also can be determined by associating DNS requests with later TLS connection to a specific IP address - unless DNS is protected to using DNS over HTTPS or similar technologies.
... why there is a need of HTTP connect packet when we have the SNI field from where proxy can find out where it needs to connect?
The ClientHello is only send after the tunnel to the server via the proxy is established. To establish the tunnel the proxy needs to know the IP address of the server. In theory the client could put the target IP address in the CONNECT request instead of the domain name. But a proxy is often used in setups where the internal client has no access to the external DNS at all, which means that the client might not be able to provide the server IP address and that the proxy must resolve the domain name.
In theory a proxy can be configured in a transparent mode where the client tries to connect directly to the final server (i.e. no CONNECT request) and due to some firewall magic these packets get redirected to the proxy which then figures out the real target by analyzing the ClientHello. And this kind of setup is not uncommon in practice. But such redirects does not work that reliable if HTTPS is used on unusual ports (i.e. not 443) since the firewall would need to first detect that HTTPS is used in the first place (using Deep Packet Inspection) in order to properly redirect. And these such DPI analysis is more expensive to do and the heuristics can also go wrong. Also, the proxy will not be able to get the server domain once ESNI is used, which means that the client already needs to resolve the domain name to the servers IP address which is a problem in restrictive environments where no outside DNS is available inside.
Apart from that, an explicit proxy allows for proxy authentication with credentials while. With an implicit transparent proxy authentication can only trybe done by source IP, i.e. there need to find outbe some previously established association between source IP and username which is not possible in environments where multiple users come from the user bysame source IP (like with windows terminal server or other thin clients).