Cooperative multithreading is useful when you have multiple entities whose actions have STRONG dependency on the other states.
There aren't many instances I can think of when it's useful. The only time I've found it particularly useful is in retro-system emulators. For example, the SNES.
The SNES has several systems:
1) CPU in charge of running actual game code
2) PPU (aka GPU) in charge or rendering pixels
3) APU, a separate processor which runs custom music/sound effect code.
4) DSP in charge of generating audio
5) Any additional hardware on the cartridge (such as the SuperFX chip on the StarFox cartridge, or the ?DSP-1? chip on Super Mario Kart)
The kicker is in real life these 5 areas are all running simulatenously, and all have constant, real-time communication with each other. So if you want to emulate them with multithreading, you're going to have to have some threads wait for other threads to sync up.
For example, every time the CPU writes to a PPU register (often hundreds of times per frame -- thousands of times per second), you have to make sure the PPU is in sync with the CPU, because the write will affect what is drawn. But you can't run the PPU ahead of the CPU because that will affect any register reads that the CPU does.
The end result is a LOT of switching between threads. Tens or hundreds of thousands of times per second. Preemptive (traditional) mulithreading performance sucks when you have this many context switches.
Cooperative multithreading, on the other hand, is ideal. When the CPU is running and it writes to a PPU register, just switch over to the PPU thread, run until you catch up to the CPU, then switch back to the CPU thread.
This is how the popular SNES emulator "bSNES" works. And in fact, I spoke with the author about this technique and employed it in my own NES emulator a while back. You can see the performance difference here:
But like I say... that's about the only example I can give where I found it useful. I'm sure there are others, but it's kind of a niche thing.