Краткий ответ

Потому что типизированный nil — это не отсутствие самого результата приведения, а значение Optional<Int>.none. Успешное приведение к Optional<Int> оборачивает это значение ещё в один Optional, поэтому результат имеет тип Int?? и форму .some(.none).

Исторический контекст

Optional был введён, чтобы отсутствие значения представлялось явно в системе типов, а не специальными sentinel-значениями вроде нуля или пустой строки. Any решает другую задачу: позволяет временно хранить значения разных конкретных типов, сохраняя их динамическую информацию для последующих проверок и приведений.

При совместном использовании Any и Optional важно различать отсутствие значения внутри Optional и результат самой операции приведения. Это и приводит к появлению двух уровней Optional.

Постановка проблемы

Значение nil нельзя хранить в Any как самостоятельное нетипизированное значение: ему нужен контекст, например Optional<Int>.none. После помещения такого значения в Any внутри контейнера остаётся именно Optional<Int>, а не «пустой Any».

Если затем выполнить условительное приведение к Optional<Int>, у операции есть собственный результат: приведение либо удалось, либо нет. Поэтому внешний уровень описывает успех приведения, а внутренний — наличие значения типа Int.

Подробное решение

Пусть в Any находится Optional<Int>.none. Целевой тип Optional<Int> совпадает с фактическим типом упакованного значения, поэтому приведение успешно. Оператор as? возвращает Optional вокруг результата приведения, и итоговый тип становится Int??.

Состояния интерпретируются так:

внешний .none — приведение не удалось;
.some(.none) — приведение удалось, но исходный Optional<Int> содержит nil;
.some(.some(число)) — приведение удалось, и внутри находится число.

Минимальный пример:

let boxed: Any = Optional<Int>.none
let result = boxed as? Int?

switch result {
case .none:
    print("приведение не удалось")
case .some(.none):
    print("успешно, внутри nil")
case .some(.some(let value)):
    print(value)
}

Ключевой момент — не смешивать успех операции приведения с наличием полезного значения. Проверка только на nil без понимания уровня Optional часто приводит к неверной логике обработки данных.

Ситуация из практики

Сервис получает неоднородные значения через Any. Для одного поля допустимы как целые числа, так и явно переданное отсутствие значения — Optional<Int>.none. Если сразу преобразовать значение к Optional<Int> и потерять различие между внешним и внутренним уровнями, можно ошибочно принять неудачное приведение за корректно переданный nil.

Варианты решения:

привести к Int — проще, но невозможно отличить типизированный nil от других случаев отсутствия значения;
привести к Int? и обработать Int?? через pattern matching — сохраняет всю информацию, но требует явного разбора уровней;
заранее нормализовать данные до конкретной модели — надёжнее на границе приложения, но требует контроля места, где формируется Any.

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

Что кандидаты часто упускают

Какой тип имеет результат условительного приведения к уже Optional-типу?

Если целевой тип — Int?, оператор as? добавляет ещё один уровень. Поэтому выражение имеет тип Int??, а не Int?. Это общее правило: результат условительного приведения имеет Optional-обёртку независимо от того, является ли целевой тип сам Optional.
Чем отличаются .none и .some(.none) у результата типа Int???

.none означает, что операция приведения завершилась неуспешно. .some(.none) означает, что приведение успешно распознало значение типа Int?, но это значение равно nil. Внешний уровень относится к операции, внутренний — к данным.
Почему проверка результата только на наличие внешнего Optional недостаточна?

Проверка внешнего уровня показывает лишь успешность приведения. После успешного результата нужно отдельно проверить внутренний Optional, иначе .some(.none) можно ошибочно интерпретировать как наличие целого числа. Для надёжной обработки применяют вложенный optional binding или pattern matching с отдельными случаями.