Does it make sense to have an HTTP connection pool and a thread executor pool for requests that originate the outbound calls at the same time?

I am working on a RESTful service that uses a fixed executor pool for outbound call requests like:

return CompletableFuture
    .supplyAsync(() -> {
      try {
        return restTemplate.exchange(uri, method, request, responseType, new Object[0]);
      } catch (IOException | URISyntaxException e) {
        e.printStackTrace();
      }
      return null;
    }, pool); //This is a thread pool executor with a fixed size
}

This restTemplate also has a fixed connection pool specified (with a lot of boilerplate I will not include) through a PoolingHttpClientConnectionManager.

I am interpreting this as unnecessarily offloading the outbound calls from the originating threads, which are blocked by the connection threads and do not perform any other tasks in the meantime. But I was unable to convince the author of this who insists on performance gains when auxiliary tasks like logging etc. are involved (which I think should be the tasks that are offloaded here)

What am I missing here?

In isolation it does seem redundant, but stepping back, it can make sense.

The main reason is that restTemplate.xx() are blocking calls. If you use them, you have to wait for the (http) response to proceed to the next instruction.

Fire and forget

Now suppose this HTTP call is a "fire and forget" call, you just send data out, and you discard (or do not need) the call's response to forge your own response. Then threading is a great way to send your response earlier.

Independant work to do

Suppose the call is important, you need its response, but you have some work to do in the meantime. Maybe you have a DB request to fetch. Maybe a file to read. Maybe another HTTP call to make, or just about anything that does not require the response of the HTTP call yet.
You can start working on that while your thread is waiting for the HTTP response.
That's a boost.

Chaining work

Suppose you are calling this one service, and with the result of this one call, you have to make two other calls, one of them need to perform a third call, and the result of all that is needed to perform a fourth call.

CompletableFutures (or other reactive programming tools) are designed for that. Anything that can run concurrently will, and dependencies are set in a declarative way that hides it. It's great, and as performant as can be.

Configuration conflicts

The rest template is based on some HTTP client, that pools connections. Connection pools have all kind of tuning parameters, e.g. total number of outbound connections/sockets, sockets per host, or per HTTP proxy, or what not.

Now suppose the HTTP call you're about to make, for some reason, is rate limited (external API technical or contractual restrictions), and the HTTP pool is not aware or configurable for that. Then using a thread pool as a controler for the number of concurrent requests can be the simplest way.