Higher throughput does not imply lower average latency. Think pipelining with lots of parallelism. Think of a system that makes everyone wait for ten minutes then sends them to one of a million cashiers. Such a system would have enormous throughput with very high latency.

Little's law doesn't imply what you said, either. It tells us the number of people in the system based on arrival and wait, but nothing about throughput.

If the number of people in the system remains constant over time, then you can measure throughput by counting the rate at which people either arrive or get processed.

And you're right about throughput, I was implicitly holding the number of people in the queue constant, and you can obviously add arbitrary delays and increase the number of people in queue without touching throughput.

Only matters if you care about average latency.

Just like the website load times, you should be focused on the 99th percentile and the median. Single line reduces those metrics.

Really this boils down to whether the business is interested in saving a bit of money (fewer cashiers per purchase) or improving customer experience.

Occasionally causing large delays while maintaining the same mean response time will increase the 99th percentile and lower the median.

The metric you want is to figure out what wait time constitutes good/acceptable/bad service, and what percentage of people get that service.