Context is not need for any code which can block.
Context is only needed where one has a dynamic graph where one wishes to cleanly tear down that graph. One can operate blocking tx/rx within a fixed graph without the need for any Context to be present.
Possibly folks are thinking of this only for "web services" type of things, where everying is being exchanged over an HTTP/HTTPS request.
However channels / CSP can be used in much wider problem realms.
The real gain I found from the CSP / Actor model approach to things is the ability to reason through the problems, and the ability to reason through the bugs.
What I found with CSP is that I accept the possibility of accidentally introducing potential deadlocks (where there is a dependancy loop in messaging) but gain the ability to reason about state / data evolution. As opposed to the "multithreaded" access to manipulate data (albeit with locks/mutexes) where one can not obviously reason through how a change occurred, and its timing.
For the bugs which occur in the two approaches, I found the deadlock with incorrect CSP to be a lot easier to debug (and fix) vs the unknown calling thread which happened to manipulate a piece of (mutex protected) shared state.
This arises from the Actor like approach of a data change only occurring in the context of the one thread.
Actor model does not need CSP. Erlang uses single message passing queue per thread (process in Erlang terminology) with unbounded buffer so the sender never blocks.
As the article pointed out lack of support for unbounded channels complicates reasoning about absence of deadlocks. For example, they are not possible at all with Erlang model.
Of cause unbounded message queues have own drawbacks, but then Erlang supports safe killing of threads from other threads so with Erlang a supervisor thread can send health pings periodically and kill the unresponsive thread.