Earlier quoted context omitted.
Why not? Thread pools are great for doing bulk operations... long API requests is a great thing to do in parallel when possible.
There's a runtime overhead of spinning up a bunch of threads that are just going to sit idle waiting for an API response. There are better asynchronous models for that sort of thing.
On my laptop, thread creation (pthread_create() followed by pthread_detach() takes ~17 microseconds.
When one end of a socket is on the Internet somewhere, connection time is ~80ms. If I start a thread and then have it create a network connection, eliminating the therad spawn overhead couldn't save more than 0.02% (that's two percent of a percent) of the running time, by Amdahl's law.
The effect of thread creation just isn't significant here. If this utility is going to spawn 1,000 simultaneous API connections to twitter, the threads could all be started by the time the first connection succeeds.
(My numbers come from a class assignment where I benchmarked some unrelated stuff, but if you're interested, I can send you the report)