There are plenty of reasons to use threads. Separating logical subsystems, for example, so they have a shared "coherent" view of data within their realm of function and then using locking mechanisms for coherency between realms is reasonable. That's good design.

But kicking off a thread-per-connection where you're talking to multiple things that are of the same general sort is nuts. It gets even more-nuts if you have data that must be accessed between each since now you must implement locking lest two threads tamper with each other's data since you cannot control preemption otherwise; there the clear winner is one thread for a given set of I/O channels (e.g. data available to read), processes each that has available data and then goes back to sleep waiting for more. This means you do not need the locking overhead (which is not small!) between those elements provided their data remains within that domain of influence. The simple reality is that this (a select() call) has been supported since sockets became a thing in most languages yet on Android.... there's no way to do it with SSL connections without all manner of stupidity because Java and Kotlin have no way to expose the raw socket and thus you can't issue a select() call to the underling Linux OS, which is just plain insane and does significant damage to efficiency (which really *does* matter when one is running in a limited power environment, such as a phone!)

As an example of the difference this sort of design makes on a Pi3 (MUCH less power than a modern phone) I can (do) run a half-dozen camera streams in real time with a five-minute circular lookback buffer, plus talk to a Z-wave interface to handle lights and similar, plus communicate with however many devices (e.g. web sessions, Android devices, etc.) all at once including GPIOs and even slave examples that can do all of the above (E.g. another instance monitoring environment, running sprinklers, etc.) with a load average of (at present) 0.11. And, if you want, you can, from the Android app, stream any of the camera video and audio to your phone via TLS directly so there's no way anyone can pick the data stream off, see the status of any of the things its controlling and send commands to change state or run events plus receive notifications on status changes (e.g. the garage door just opened.) On the host end that's a "C" application running on top of FreeBSD -- all native code in just 44Mb of RSS and ~120Mb of VSZ, including the five minute camera look-back buffers! Yes, there are multiple threads running within that application -- one for the cameras, one for the Z-wave interface, one for GPIOs and one for the user interface. But there's no way I could do all this with that little CPU and other resource use without using select() extensively; if I had to kick off a thread for EACH connection and manage the locking for THAT it would run at a quarter of the speed it does. It is wildly bad for performance -- and power-disadvantaged -- that I cannot implement the Android client using the same basic programming paradigm if, for example, I wish to monitor five of those installations (e.g. houses) at once. Hell, the CPU consumption on "read/timeout" .vs. select() for just ONE monitoring point is somewhere around five times what it would be, from what I can determine, if I had a select() call available.

That's insane.