It wouldn't. That's literally what coroutines are. In-process, lightweight, cooperative multitasking, built in as a language feature (or at least close enough to it).
It is not. Coroutines are a much more fundamental feature. They can be used to implement cooperative multitasking, and since that is such a common use case, they have gotten confused with the concept of cooperative multitasking.
Actual coroutines are a lot more flexible and interesting than just cooperative multitasking, though.
Erm, I'm pretty sure I can implement coroutines using cooperative multitasking. Also, the other way around. So I'd say they're equivalent in that sense.
Now you're really just making claims about implementation details. That doesn't make one concept more "fundamental" or "flexible" than the other, while "interesting" is just a subjective judgement.
I'm not. The scheduler decides what code to execute next, the caller does not. With coroutines, the caller explicitly decides what code to execute next. That's a fundamental difference.
Coroutines and cooperative threading/multitasking are indeed threading. I assume they meant to say that it was neither preemptive nor parallel, which makes it somewhat limited. Some people think a system has to be one or both of those to be called threading.
For me, and for a vast majority of people I'd say, the word "threading" in common parlance implies pre-emptive scheduling with implicit synchronization points.