HoBTIDПравильно ли я понял, что GC проще удалить 100 (1000, 1 000 000, сколько???) короткоживущих объектов,
чем 1 долгоживущий?
Дело не в том что "проще". А в том как это всё вообще работает.
Пересоздание - ОК. Потратили немного больше на allocation.
Вышли за пределы блока. Если escape analysis отработал успешно (а его, вроде, с каждой версией Java всё лучше допиливают).
Объект умер быстро своей смертью.
Даже без escape analysis он быстро уберется из Eden.
К вашему вопросу о количестве... - количество убираемых объектов влияет на производительность напорядки меньше чем количество найденых живых. GC сканирует именно живые объекты. Все которы мы создали и забыл, он просто не найдёт и удалит. Причем пачкой - что очень быстро.

Теперь если объекты переиспользовать. Мы же не говорим про Hello World, который ничего не делает, кроме как использует один единственный StringBuilder. Мы же говорим о некой, потенциально большой, системе? Если вы решили переиспользовать объекты, значит вы это будете делать не в одном месте. А во многих. Ведь вы считаете что это быстрее, чем создавать новые. Поэтому придерживаетесь этого подхода.
Таким образом ваш объект оседает в Eden, перемещается в survived и в конце-концов оседает в tenured. Ваш объект всегда нужен и всегда живой. Поэтому он сканируется при каждой сборке в Tenured. И влияет на производительность всей системы.

Мой ответ не претендует на полноценность, так как стоит рассмотреть альтернативные алгоритмы сборки, такие как G1.
Кроме этого, не исключено что в готовой системе можно и с массой объектов tenured свести работу к GC к минимум тонкими настройками. Но это всё индивидуально для каждого проекта.

HoBTIDМы же не сравниваем 1 короткоживущий и 1 долгоживущий.
Сравниваем, не понятно что, не понятно с чем. Я же говорю про общий случай. А вы всё пытаетесь свести к одному единственому, в котором переиспользование вдруг окажется быстрее. Конечно бывают варианты, когда переиспользование окажется выгоднее. Но это не значит что переиспользование выгодне во всех случаях.