Your claim, that the latency cost of reflection is small in comparison to the latency of performing I/O, seems reasonable assuming that the service is processing only one request at a time. That is not the case for typical microservice architectures and certainly not what is happening in the load test by which each of these service implementations are compared.
There is an upper limit of requests to which any service can handle concurrently. Usually, that limit is based on memory but there could be other factors too. After that upper limit is reached, additional requests wait in a queue or get rejected. From Little's Law, we know that the number of requests in any system is the product of the rate of ingress and the average time it takes to service a request. Since that number of requests is bounded, even small increases in the average process time can have a significant negative impact on the ingress rate that the service can sustainable handle. If you are not familiar with queuing theory, then perhaps you have heard of onlooker delay being the major cause of traffic jams.
Is running Clojure services with Java reflection the end of the world? Of course not. Just be aware that it does make performance for those kind of services look not quite as efficient when compared with services that do not use Java reflection.
