Destroying locality makes the program very difficult to read for anyone other than the person who wrote it. I've been there before and done that. I've written Z80 assembly code where functions had more than one entry point as well as exit point. Sometimes I didn't bother to keep a stack at all. Spaghetti code. I was proud of it at the time. Not so much now.
My understanding of Corotwine and greenlet is that they're basically poor man's threads. Basically, if the language doesn't give you usable threads, you can go ahead and implement your own. I've done that one too-- I once wrote an M:N threading library in userspace. Basically making a small number of kernel threads look like a large number of threads to the programmer.
The problem with rolling your own threads is that the normal tooling that comes with the language won't know how to handle what you built. There is no syntax for your add-on, and the semantics may be murky at best. Stack traces become useless, and error messages become guru meditations. Interfacing with third party libraries becomes a challenge, unless they're designed to be purely single threaded.
Additionally-- how to put this delicately? Something as fundamental as threads should not be built as an add-on to a programming language. Things built on top of a language tend to be very fragile and buggy compared to things built in to a language. The C programming language was designed before threads were even a thing in UNIX, so lacking threads was understandable. We built our own threading packages because we had to. But you shouldn't need to do that for a modern language.
This will certainly improve the situation with interfacing different Python libraries together if it gets adopted. I still don't think asynchronous APIs are as easy to use as blocking ones, but I guess I've said enough about that already :)
What impact do you feel the destruction of locality has, specifically?
Do you feel @inlineCallbacks and Corotwine answer these issues?