Зачем нужны неявно извлекаемые опционалы (Implicitly Unwrapped Optionals), если мы и так уверены, что там есть значение?

Краткий ответ: IUO — это мост между миром Optional и Non-Optional

Вы правы, что IUO (Implicitly Unwrapped Optional) выглядит как противоречие. Но на самом деле это очень полезный инструмент для решения конкретной проблемы: отложенной инициализации, когда значение гарантированно появится после создания объекта, но не во время его инициализации.

Главный пример: @IBOutlet в UIKit

Ваш пример с кнопкой — классика. Вот почему там используется IUO:

class ViewController: UIViewController {
    @IBOutlet weak var button: UIButton!  // IUO
    // Нельзя написать просто var button: UIButton
    // Потому что при инициализации ViewController'а кнопки ещё нет!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        // Теперь кнопка точно существует
        button.setTitle("Нажми меня", for: .normal) // Работает без разворачивания
    }
}

Когда создаётся экземпляр ViewController, его view ещё не загружена из storyboard. Свойство button физически не может быть установлено в конструкторе — оно будет присвоено системой позже, когда загрузится nib-файл (обычно при первом обращении к view).

Если бы мы написали var button: UIButton, компилятор потребовал бы инициализировать это свойство в init(), что невозможно. Если бы мы написали var button: UIButton?, то при каждом обращении пришлось бы писать button!.setTitle(...) или if let, что раздражает, ведь мы знаем, что после viewDidLoad кнопка точно есть.

IUO решает эту проблему: компилятор разрешает оставить свойство без значения при инициализации (как опционал), но при обращении ведёт себя как обычный тип (не требует разворачивания).

Когда использовать IUO (исторически)

• @IBOutlet — как показано выше, это было основное применение
• Свойства, инициализируемые в init() другого объекта — например, при внедрении зависимостей через storyboard
• API Objective-C — многие старые Cocoa-фреймворки возвращали IUO для совместимости

Важное предостережение (Swift 5.7+)

Начиная с Swift 5.7, поведение IUO изменилось. Теперь String! — это просто синтаксический сахар для Optional<String> с особым поведением только в местах, где ожидается non-optional тип. Компилятор больше не создаёт специальный тип. В современном Swift рекомендуется:

• Для @IBOutlet использовать var button: UIButton! — это всё ещё стандарт
• Для новых проектов — рассмотреть @IBOutlet var button: UIButton? с последующей проверкой
• В остальных случаях — избегать IUO и использовать обычные опционалы с guard let или if let

Почему IUO — это плохо в общем случае?

Если вы используете IUO для обычных свойств, вы теряете безопасность. Пример опасного кода:

var name: String! = nil
name = "Alice"
print(name.count) // Работает
name = nil
print(name.count) // CRASH! Unexpectedly found nil

Код падает без понятного сообщения об ошибке. С обычным опционалом вы бы написали if let и избежали краша.

Итог

Используйте IUO только в тех случаях, где вы абсолютно уверены, что значение будет установлено до первого чтения, и не можете инициализировать его в конструкторе. Для всего остального — обычные опционалы с безопасным разворачиванием.