I have to limit number of threads as they are consuming considerable amounts of memory.

The memory footprint of threads can usually be dramatically reduced with very little effort.

IO handles can't be shared between threads, so once my thread worker connect to remote address I have to use this particular worker for all future communication,

Not so. IO handles can be reopened in multiple threads; though it is rarely useful to do so.

Almost always the desire to do so indicates a bad design.

which doesn't go well along with worker pattern. http://www.perlmonks.org/?node_id=967149

That argument makes no sense. The boss says, create a telnet connection to these machines and perform this/these tasks -- by queuing the relevant session information -- and the workers dequeue a set of instructions and perform them.

everything is shared

True. Everything is shared -- which means you have manage the problem of ensuring that different contexts do not trample all over each others private data.

/no need for variable locking

True. No need to lock since only one execution context can run at any given time.

Which means if you have a 16 core machine you're ignoring 93.75% of your potential cpu and wasting 10%+ of the one cpu you are utilising, perform crude context swapping in user level code; and another 5% fighting the system scheduler.

But if you really want to return to the mid-90s, Windows95-style of cooperative multitasking, with all of its inherent problems...