I don't believe that you have too many active connections for threading to work. Passive connections can be handled by a single or small number of threads. Modern Linux on modern hardware has no problem with many thousands of threads and the overhead is minimal in $$$ compared to the time you wasted debugging a scheduling problem.
As for concurrent systems being harmful, you just have to design your program for threading in mind. Minimize shared state and be very careful when you can't.
> the overhead is minimal in $$$ compared to the time you wasted debugging a scheduling problem.
Better than time wasted debugging the races and deadlocks that only threads can cause. These are much harder to debug because they are so much harder to examine without changing behaviour.
Sure, there's a trade-off - so there's no point in pretending that there are no downsides to using threads.
I would redesign your protocol to be request/response based akin to http. Achieve performance by using multiple connections in the client. Simplicity > efficiency especially if you don't have the engineering resources of a company like Google.
And I'm out. The reply rate limiting is infuriating.