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.
Even if starting a new thread takes 1ms, that pales in comparison to the 300ms network connection.
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)
No, long parallel requests are great to do concurrently on a single thread. A thread is a computation primitive, you spin off a thread when you want to compute many things at once, not just wait for many things at once.
If you would spin up threads just for this you're wasting memory and slowing down startup time.
And if you would destroy the threads and spin them up again for every batch of API calls, the result may counterintuitively be a slower app due to the overhead of creating the threads themselves.
At the same time concurrency is free. There's no overhead for doing a call async.