I'm not sure I understand your concern here. How does monocle make decomposing logic into functions difficult?
The "yield" keyword is an indicator of where control is returned back up to the event loop and other things can happen. We like that in monocle, because we view it as dangerous; in thread-and-lock terms, it's sort of like "unlock everything".
Eventlet (http://eventlet.net/) is an example of a similar framework that decided not to require "yield" at these points.
Let me start by saying that I actually think Monocle is nice work given the language mechanisms that Python provides and this is intended as constructive criticism.
What I meant by "makes it hard" is that it creates two different calling conventions for functions and you need to know how a function is implemented to determine which one to use. Also, if the implementation of a function changes you may need to find and change all the call sites of the function. These are not insurmountable problems by any means, but they are extra potential sources of error in a program.
I'm not familiar with Eventlet, but FWIW the Cocoon framework (http://cocoon.apache.org/) had a quite nice take on this model back in the day.
The "yield" keyword is an indicator of where control is returned back up to the event loop and other things can happen. We like that in monocle, because we view it as dangerous; in thread-and-lock terms, it's sort of like "unlock everything".
Eventlet (http://eventlet.net/) is an example of a similar framework that decided not to require "yield" at these points.