Разыменование nullptr без фактического обращения - почему нельзя?

"UB" - не то же самое, что "код не работает".

пример кода, где ... приведёт к реальному UB!

UB - это то, про что в стандарте написано, что это UB (либо то, про что в стандарте вообще ничего не написано - но это редкость).

Из этого следует, что наличие UB нельзя определить, глядя на вывод программы или в дизассемблер. Нужно смотреть в стандарт, а там написано вот что:

[expr.unary.op]/1

... If the operand points to an object or function, the result denotes that object or function; otherwise, the behavior is undefined except as specified in [expr.typeid].

То есть неважно, используется результат или нет - все равно UB. (Единственное место, где это можно делать без UB - в аргументе typeid(...)).

Почему в стандарте так написано? Предполагаю, что потому, что в компиляторах есть оптимизации, и для целей оптимизации удобно считать, что UB никогда не происходит (компилятор может не заходить в ветку if, в которой видит разыменовывание нулевого указателя, экономя на проверке условия, и т.п.).

Проще оптимизировать, считая что нулевые указатели никогда не разыменовываются, чем вводить хитрые правила, когда результат считается "использованным", а когда нет.

Можно ли так делать на практике?

Пытаться оправдывать UB есть смысл, только когда оно дает какие-то новые возможности. Когда есть стандартный offsetof(...), незачем оправдывать свою реализацию.

Даже если на вашем компиляторе это вроде работает, вы уверены, что это не сломается в каком-то другом месте кода, при обновлении или смене компилятора, или при изменении флажков?

Когда у вас в следующий раз появятся таинственные краши непонятно где, вам придется перепроверять все свои грязные хаки.

Если хотите реальные примеры, то вот. Не совсем то же самое, но похоже. При обновлении на GCC 6 сломались Хром, Qt и KDevelop, потому что GCC стал выбрасывать проверки this != nullptr, потому что вызов метода на нулевом указателе - UB, даже если никакие поля оттуда не читаются.

Ну и: (но это не столько про UB, сколько про недостаточные проверки в макросе)

#include <iostream>

#define OFFSET_OF(TData, field) ((char*)&(((TData*)nullptr)->field) - (char*)nullptr)

struct A {int field;};
struct B : virtual A {};

int main()
{
    std::cout << OFFSET_OF(B, field) << '\n';
}

На GCC ошибка компиляции, на Clang - краш.

Небольшой ликбез по UB: Стандарт языка описывает эффекты от использования различных языковых конструкций в виде работы некоторой абстрактной вычислительной машины. А Неопределенное Поведение - это те случаи, когда поведение этой абстрактной вычислительной машины в стандарте не определено. От компиляторов же стандарт требует, чтобы в ходе реального выполнения программы она выдавала то же Наблюдаемое Поведение, что и описываемая в стандарте абстрактная вычислительная машина.

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

В фразе "Видим, что всё работает как надо. Компилятор, как и ожидалось, предвычислил значения смещений на этапе компиляции." оборот "как и ожидалось" не имеет под собой оснований. И вообще любые попытки определить наличие или отсутствие в коде Неопределенного Поведения путем сборки и выполнения программы обречены на неудачу.

"Однако в моём предыдущем вопросе один не особо дружелюбный пользователь назвал такой код вакханалией и бредом. Мол, тут разыменуется nullptr, и по-этому так делать нельзя." - да, вакханалия там еще та, причем разыменование нулевого указателя там как вишенка на торте из других проблем.