When is cooperative scheduling actually a good choice?

When you want the simplicity and reduced synchronization burden of non-preemption and you can guarantee every task yields promptly. Because a cooperatively-scheduled task is never interrupted by another task except where it explicitly yields or blocks, data shared between tasks is implicitly safe between those yield points, so you can often avoid mutexes and critical sections, fewer concurrency bugs, easier reasoning, lower overhead. That's attractive for small, well-understood systems where the task set is fixed and you control all the code, similar in spirit to a structured super-loop. It's a poor choice when you have hard real-time deadlines that require preempting a long-running lower-priority computation, when tasks call into third-party or blocking-but-not-yielding code you don't control, or when one task's misbehavior (an unexpected long loop, a missing yield) hanging the whole system is unacceptable, which is most production real-time systems, hence preemptive being the default. There's also a hybrid reality: even preemptive systems gain cooperative-like safety inside critical sections and when tasks at the same priority don't time-slice. So cooperative is a deliberate choice for simple, fully-controlled, latency-tolerant systems where the synchronization savings outweigh the loss of forced preemption, not a default for real-time work.