Жизненный цикл UIViewController'a

self.view = nil НЕ вызовет viewDidUnload
self.view = nil Лишь обнулит переменную _view, что в свою очередь при следующем доступе к self.view приведет к повторному вызову loadView.

А dealloc в библиотеке Three20 выглядит примерно так

- (void)dealloc {
...
// You would think UIViewController would call this in dealloc, but it doesn't!
// I would prefer not to have to redundantly put all view releases in dealloc and
// viewDidUnload, so my solution is just to call viewDidUnload here.
[self viewDidUnload];

[super dealloc];
}

Разумеется не при каждой. Давайте разберемся, при каких обстоятельствах self.view может стать nil? Только в двух —

1) если в коде программы явно прописан такой вызов (я делаю так крайне редко и эти случаи обслуживаются очень отдельно с учетом всех последствий)

2) Программа получила предупреждение о нехватке памяти и выгрузила те из вьюшек, которые либо не были в данный момент видны (лежат на соседней вкладке tabbarcontrollerа, лежат на нижнем уровне стека UINavigationController, нигде не лежат — т.е. self.view.superview == nil (это заметим, не случается с модальными контроллерами, в которых и осуществляется основная привязка данных к вьюхам — тут можно вообще особо не стараться с отслеживанием isViewLoaded — практически шанс того, что вьюха модального контроллера будет выгружена из памяти стремится к нулю). Причем если контроллер был создан на основе xib или контроллер переопределил loadView то при этом будет вызван viewDidUnload — в нем можно все обнулить.

Вот как раз второй случай и рассмотрим. А точнее рассмотрим те из вьюшек, обращения к которым надо проверять с isViewLoaded. При внимательном рассмотрении оказывается, что таких контролов до обидного мало. В большинстве случаев они либо статичны — текст на них не меняется с момента создания (кнопки, лейблы) либо они сами умеют себя обслуживать — таблицы через делегаты или срабатывания кнопок — пока кнопки и таблицы живы они сами о себе позаботятся.

Ситуаций, когда валидность именно этого член класса (_label) к именно этому контроллеру имеет смысл проверять оказывается на практике ну очень мало. Настолько мало, что тут не имеет смысл городить более сложный огород. Да и вообще, как правило, вся информация на форме меняется в одном месте и делается через что-то вроде

-(void)updateData {
if (self.isViewLoaded) {
…
}
}
// кстати этот вариант сработал бы на любом языке, а вариант с обнулением _label
// сработает только в Obj-C, где средствами языка разработчику предоставляются
// поблажка — конструкция [nil somemethod] не является фатальной.
// Если бы этой поблажки не было бы, то пришлось бы еще и проверять на _label != nil
// – вас это тоже возмущало бы?

Безусловно, всякие случаи бывают и по всякому нужен свой подход. Вы — за системность подхода. Я больше склоняюсь практичности. Не такое это сложное дело — отловить это проблемное место, если где что и позабыл вдруг.