Yes, UDP is connectionless. It fires off it datagram, then it forgets about it.
The UDP in one host did not negotiate and create a connection with the UDP in the other host. One of the hosts could simply go away, and the other host would never know because there is no connection.
An application still needs to tell UDP to open a UDP port to send something, and it needs to tell UDP the destination port. That is what you are seeing, but that is not actually a connection the way TCP in one host negotiates with TCP in a different host. UDP does not negotiate or maintain a connection, it will simply send a datagram. Also, the application can close the UDP socket, and UDP simply forgets it, it doesn't negotiate closing a connection with UDP in the other host.
There is much more to a TCP connection than simply the addressing, even though a TCP connection is identified by the addressing. RFC 793, Transmission Control Protocol explains:
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for each
data stream. The combination of this information, including sockets,
sequence numbers, and window sizes, is called a connection. Each
connection is uniquely specified by a pair of sockets identifying its
two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid erroneous
initialization of connections.
Host OSes are actually off-topic here, and how a host OS implements something like UDP is off-topic, although the protocol theory for UDP is on-topic.