Most of the steaming platforms use HTTP Live Streaming (HLS) because it avoids all the networking NAT headaches that come with p2p connections and it handles variable quality better because each client fetches the best quality for their bandwidth. As far as I know, with WebRTC the sender degrades quality to satisfy the slowest peer.
That said, the downsides of HLS are potentially higher infrastructure costs required to transcode video to the different qualities and somewhat related is the higher latency to live. With proper tweaking you might get 2-3 seconds of latency, but it might be too much for your use case.
If there is voice interaction between the yoga instructor and their students the HLS delay will certainly be noticeable.
> WebRTC the sender degrades quality to satisfy the slowest peer
No, WebRTC is 1 to 1. Each connection is adapted independently. But, you can build services that have rooms with more participants, then it's up to you to shape the traffic as you want. If you use a central server (SFU), it can just send each peer the best they can receive, each independently from one another. It's a property of the service, not the technology.
That said, the downsides of HLS are potentially higher infrastructure costs required to transcode video to the different qualities and somewhat related is the higher latency to live. With proper tweaking you might get 2-3 seconds of latency, but it might be too much for your use case.
If there is voice interaction between the yoga instructor and their students the HLS delay will certainly be noticeable.