I've been in the industry long enough to remember the issues with the Mac OS when it was still cooperative. Having continuations is sort of neat, but selling it as a threading solution rather ignores decades of experience that pretty uniformly point towards it being incredibly problematic for that purpose, to the point that I wouldn't touch it with a ten foot pole. There's a reason all OSes use preemptive scheduling. All the benefits of cooperative scheduling come with gigantic tradeoffs that dwarf the benefits, such as the ability of one cooperative unit to suddenly stop cooperating and halt the whole shebang, which pretty inevitably happens. (It doesn't even have to be a "crash", just a fiber that wants to, say, find and replace a string in one pass but suddently gets passed a multi-gigabyte string. This sort of thing happens all the time, and if you think you can avoid it... I don't believe you, but you're free to try. The problem space of reality is a lot spikier than anyone can imagine.)

Also, if Ruby really does schedule an I/O-locked thread for its full slice regardless of it being locked, that's Ruby's problem, and "fixing" that is not an advantage of cooperative scheduling. However, I doubt Ruby works that way. Somebody please tell me it doesn't.

It's a great tool for many other tasks, no question. But it's really questionable to use it for scheduling. If you feel it's the best tool, be sure you understand the tradeoffs before diving head-first on the basis of one article's breathless summary. There are reasons this approach has been abandoned for scheduling, and why virtually nobody is proposing that it come back for that purpose, even with all the recent interest in such matters.