а гугл что думает?

questionerгугл говорит, что они обратны,

Не всегда, но зачастую.

questioner но в concurrency in practice пишут, что нам надо добиться и того и того

Опять домыслы? Может не надо а хочется? А иногда на самом деле получается и то и другое.
questioner как будто мы это по разному долждны это делать
Ну вы сами себе противоречите, если это разные вещи то они и должны делаться по-разному?

В целом, стратегии достижения минимальной latency\максимального throughput действительно отличаются, иногда довольно сильно. В некоторых же случаях, можно улучшить и то и другое.

В общем вопрос опять из серии, прочитал что-то но не понял и не могу сформулировать.

На примере Java и GC - low latency сильно упирается в производительность GC, тут либо вообще добиться чтобы сборок не было(что почти нереально), либо не допускать STW-пауз блокирующих приложение надолго. В этом случае minor сборки будут работать почти постоянно, но быстро, сжирая нехилую часть CPU. Зато latency более-менее предсказуемый.
High throughput с другой стороны достигается методами "пакетной" обработки, нам не важна скорость, важно что ресурсы(CPU\память) будут расходоваться оптимально. Поэтому STW паузы допустимы, и они будут меньше кушать CPU.

Надо добавить, что Java в принципе не сильно хорошо подходит для low latency по своей архитектуре, сделать паузы менее 5-8 мкс практически невозможно