You're not sending unencrypted streams to Jitsi, as it uses hop-by-hop encryption, meaning you send an encrypted stream to the server where it gets decrypted and re-encrypted for the rest of the participants. At no point you are sending "plaintext" data. What you might have heard is that Jitsi will be introducing end-to-end encryption, but it doesn't mean it doesn't have encryption at the moment.[1]
I think it's a misnomer to say WebRTC end to end encrypted by default.
If you cannot guarantee end to end encryption during the negotiation phase, you cannot trust that the party you're encrypting for/receiving encrypted content from is the actual party you are expecting to communicate with, hence the need to independently verify over a trusted channel whether the fingerprint in the SDP offer/answer matches.
After the negotiation is complete, the streams will indeed be encrypted, but if the offer/answer SDP has been tampered with by the signaling server, which is under the control of a rogue/compelled provider, and another DTLS certificate has been inserted, the encryption is useless as far as complete communication security is concerned.
