A quick look over the source code shows that they do not use an SFU - as such they will be LIKELY be full mesh p2p, and therefore e2e encrypted by default - I don't have the time to verify this, but I understand they are audited for this kind of thing.
The downside to this architecture is that it is not very scalable (i.e. limited participants in a room). There are some ways around this using a lot of signalling between peers to throttle feeds, but you will still always be "uploading" a stream per peer.
I'm not sure how much relaying skype supernodes did, but as skype wasnt webrtc-based they would have more control over stream encryption - allowing routing of encrtpyed streams for true e2e encryption.
For small webrtc conferences, treating certain peers as an SFU can certainly work. However, bandwidth requirements would be substantially higher than full-mesh for the supernodes, and equivalent to SFU peers for non supernodes - so supernodes would need to be chosen wisely (and you would still be very limited on number of participants - then you are entering the realms of peering supernodes and intelligent routing of streams). Additionally, this still wouldn't be e2e encrypted. Its just a (current) limitation of webrtc.
The downside to this architecture is that it is not very scalable (i.e. limited participants in a room). There are some ways around this using a lot of signalling between peers to throttle feeds, but you will still always be "uploading" a stream per peer.