Ну допустим аллокации быстрые, т.к. до следующего GC цикла с компактификацией менеджеру кучи не нужно искать какое-нибудь свободное место подходящего размера. Но это не отменяет того, что непрямой доступ (по ссылке, которая по сути, неявный указатель) сохраняется и даже если объекты сидят в начале памяти, GC не делает их группировку по смыслу при размещении по фактическим адресам в памяти, так сказать. Т.е. допустим есть несколько List коллекций, даже если прошло сжатие кучи и все списки перемещены и "уплотнены" в начале кучи, это абсолютно не значит, что объекты не перемешаны друг относительно друга в рандомном порядке (т.к. GC работает в несколько параллельных потоков, намеренно не синхронизированных, ордеринг по размещению в памяти не сохраняется). А это выливается в то, что когда проц грузит данные в кэши, то в кэш-линиях соседствуют друг с другом данные, не связанные по смыслу. Из-за чего cache miss постоянный и связанные с ним издержки. В каком-нибудь хайлоаде с могучим RPS это имеет значение. Не зря же исписали кучу статей и исследований про data oriented programming и mechanical sympathy. Поэтому все и просят постоянно, чтобы добавили в язык "плоские" структуры и аллокацию на стеке, чтобы затрагивать хип только когда нужно, а не "почти всегда".