STUN is designed to discover client's Public IP Address if the client is sitting behind NAT.
STUN messages are usually sent in User Datagram Protocol (UDP) packets. Since UDP does not provide reliable transport guarantees, reliability is achieved by application-controlled retransmissions of the STUN requests. STUN servers do not implement any reliability mechanism for their responses. When reliability is mandatory, the Transmission Control Protocol (TCP) may be used, but induces extra networking overhead. In security-sensitive applications, STUN may be transported and encrypted byTransport Layer Security (TLS). The standard listening port number for a STUN server is 3478 for UDP and TCP, and 5349 for TLS.
It means that your connection with the STUN server may or may not be always encrypted. It depends on the type of application.
Once the client has discovered its public IP and behind what type of NAT it is sitting at, the connection with the STUN server is terminated to save network resources. STUN uses 2 IP Address.
How do peers communicate then?
The work of STUN is over and now it's time to start a session between peerA and peerB. For P2P communication, Session Initiation Protocol (SIP) like VoIP & Session Description Protocol (SDP) are used.
If the STUN isn't encrypted, does that mean any protocol communicating through the UDP also won't be encrypted?
No. It doesn't depend on whether or not have you used secured channel for communicating with STUN. The session between both the peers will be end-to-end encrypted regardless your secured/unsecured connection with STUN. It is the responsibility of P2P service provider to ensure encrypted & secured channel for your P2P session.
If your connection with STUN is not private then the only information that can be captured is your public&private IP, external and internal ports and the type of NAT you are using.