Ещё раз (надеюсь, последний) про double-checked locking

Ну, так в данном примере ошибка — никто и не спорит.

И как это к обсуждаемой теме относится? Там я как понял как раз подтверждается атомарность создания объекта:

C tc = // initialize object + metadata
tc.f = 42; // initialize final field
[LoadStore|StoreStore]
c = tc; // publish

Object o1;
volatile Object o2;

private void m1() {
  o1 = ...;
  o2 = ...; // volatile write, happens before reading o2, 
  // so writting o1 happens before reading o2 (transitive)
}

private void m2() {
  // m1() in other thread
  o1.toString(); // unsafe, no happens before relation to o1 write
}

private void m3() {
  // m1() in other thread
  o1.toString(); // can be either visible or not
  o2.toString();
}

private void m4() {
  // m1() in other thread
  o2.toString(); // volatile read, o1 initialization is visible on next string
  o1.toString();
}

В функции m3 всё может выглядеть рабочим, а может ломаться. В m4 же всё ок. То, что эта перестановка (m4->m3) вносит гейзенбаг может быть неочевидно для модифицирующего код. Решит какой-нибудь junior поставить два независимых вызова по алфавиту, что в этом такого…

Извините, что некорректно использовал термин reordering.

Можно ссылку сохранить, но тогда нужно помнить об этом каждый раз. И если забыть, то всё будет работать.

Ссылку можно сохранять, но тогда нужно об этом помнить и если забыть даже в критичном месте, то на тестах оно никак не проявится (кроме производительности). С флагом забыть нельзя (можно только вообще про синхронизацию забыть, но тогда уж ССЗБ).
Ясен перец, что для синхронизации нужно сделать минимум одно volatile чтения. я говор о том, что применяя в качестве флага DCL полезные данные (а не отдельный флаг) можно легко забыть о том, что обращение к этим данным не просто относительно тяжёлая операция, но ещё и «ломает» оптимизацию окружающего кода.

Подумайте сами: для какой-либо синхронизации, вы в любом случае должны сделать хоть одно volatile чтение чего угодно.

Строго говоря не чего угодно, а той же переменной. Если смотреть в новый jls8, 17.4.4-5, то там сказано

A write to a volatile variable v (§8.3.1.4) synchronizes-with all subsequent reads of v by any thread (where «subsequent» is defined according to the synchronization order).

У меня может быть ещё 10 методов где используются эти переменные. Если у Вас 10 лёгких методов и 1 тяжёлый, то даже относительно редкий вызов тяжёлого, если он замедлится на два-три порядка может оказать заметное влияние на производительность. Более того, где гарантия что эти лёгкие методы в результате.
И разве я говорил о том, что DCL на полезных данных всегда плохо? Я лишь говорю, что при этом могут быть побочные эффекты в плане производительности.
Например, я видел код, в котором был DCL на полезный данных. Но по мере развития проекта эти данные использовались всё чаще и чаще. В конце концов начались проблемы с производительностью. Расследование показало, что виновато часто используемое volatile-поле. Ведь у Вас DCL может один раз отработать при запуске, например, какого-нибудь worker'а, который потом будет с этими данными активно работать (повторная синхронизация уже не нужна будет). И в этом worker'е volatile переменная запросто может использовать очень часто в любых циклах.
В конце-концов DCL не только для синглтонов используется. Это именно патерн синхронизации и использоваться он может для самых различных целей синхронизации.

Ну, раз мы говорим о DCL, то по какой-то причине он у нас уже появился :) Значит кто-то где-то с этими данными часто многопоточно работает на чтение (на самом деле это не единственная возможная причина использования DCL — например, может просто не быть «удобного» объекта синхронизации, если пишется какая-то универсальная библиотека).

И если этот код часто вызывают 50 процессов, то что случиться? Поляжет этот synchorize и положит производительность. Как раз, если тут больше десятка процессов и/или оно часто вызывается, то не нужно обычную синхронизацию делать.