Unless I'm misunderstanding you, you seem to be conflating purity with callback vs. coroutine--I'm don't know why the second would have any bearing one way or the other on the approach to the first.
If you don't want global variables, don't use them! If you don't want side effects, don't use them either. Those are the same decisions you make, callback or not. Both are great ideas.
Example 1 (callbacks):
function do_request() {
return get_from_database(argument,
callback=function (database_rows) {
return make_html_table_from_rows(database_rows);
});
}
Example 2 (coroutines):
function do_request() {
database_rows = get_from_database(argument);
return make_html_table_from_rows(database_rows);
}
What about the second requires a vastly different approach to state? What about the io loop "up the stack" has fewer effects or global variables than the loop called into at the coroutine?
In fact, clean state management is easier!
Example 3 (coroutines):
function do_request() {
database_rows = get_from_database(argument);
tweets = use_twitter_rest_api(...);
return make_html_table_from_rows(tweets, database_rows);
}
I can do the first two calls serially without either passing through the first, or using a global variable or some kind of catch all "context". The local frame is the context, which is the oldest, most straightforward, most tried-and-true context in the book.