A connect() scan generally refers to a network scan that performs a full TCP three-way handshake (SYN, SYN/ACK, ACK) in order to determine whether a port is open or not. Once those three packets have been transmitted by the respective hosts there is a connection open and ready to pass traffic. The scanner will then either close the connection with a RST or FIN, or they could conceivably just stop using it and eventually the server will time it out and recover the resources.
There are many alternatives, the most common being a SYN scan - the scanner sends a SYN and waits for a SYN/ACK. If it sees it, it concludes the port is open, even though it hasn't fully opened a connection. The scanner does not send an ACK to complete the connection, and the server's TCP stack will close out the nascent connection in response to a RST or after (far shorter) timeouts (than are used for open connections).
connect() scans are generally easier to detect, because applications often log fully opened and closed connections, especially connections that close at the TCP instead of at the application layer (e.g., they'll complain that "IP a.b.c.d DIDN'T SAY GOODBYE"). This makes a connect() scan easier to detect. Also, because OS resources are dedicated for fully opened connections, it is possible to tax resources on a host by nailing up a bunch of connections and then not using them - e.g., the "timeout" method is particularly rude.
The reason one might use a connect() scan (-sT in nmap) is that it's more reliable. Nothing says "a host will talk on this port" like getting the host fully ready and willing to talk on that port. Some other scan modes may have false positives. There have been times I re-scanned individual ports that appeared open to SYN scans and was unable to verify the port was open with connect() mode scans.
(N.B. ALL scan modes can have false positives. As my therapist likes to say, "Don't believe everything you think.")