It's an irrelevant implementation detail. This is for a live call. You are streaming video at the same time, so there's no point in worrying about idling.
I'd even say that it's a good example for others, because the equivalent code with the event loop would be slightly more complicated (maybe 5 more lines?). Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example.
My guess is that somebody coded that event-loop-less X client not really familiar with the language and how to write Xlib apps. I partially assume this because C, C++ and especially Xlib are becoming less popular over time, so finding skilled practitioners to write it idiomatically is relatively rare now. This basic event loop stuff is something that maybe belongs in a library. So they just wrote library grade functionality themselves, badly. The commentary here is getting defensive about doing things the wrong way, coming up with lots of post hoc justification.
> You are streaming video at the same time, so there's no point in worrying about idling.
I'd argue it's completely opposite of this. You're streaming video, already putting some significant stress on the system. No reason to waste time (even if it's a minuscule amount) to make things worse.
> Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example.
And that's how we ended with e.g. modern IoT that kinda sorta works but accumulation of minor bad decisions (and some less minor bad decisions for sure) ends up making the whole thing a hot mess.
Sleeping for 100ms between checking for events will not produce a noticeable CPU load. The only reason this would drain the battery is because it can prevent the CPU from entering deeper powersaving states - but even for that 100ms is an eternity and video streaming will prevent that anyway.
Not that this matters for this particular tool.