Обертка - это сокрытие реализации (принцип ООП), как раз смысл писать её есть только во втором случае, т.к. в готовом проекте уже понапиханы в коде $_SESSION и проще просто сделать session_set_save_handler. Скорее я задам себе другие вопросы: Если я выберу ваш вариант, какие преимущества я получу при отказе от давно проверенного, зарекомендовавшего себя решения? Так ли это хорошо, чтобы я тратил на это время, которое я возможно мог бы посвятить более серьезным вещам?

Также в защиту сессий скажу - им куки вообще не нужны, можно просто передать PHPSESSID, или, например, можно инициировать сессию, даже не получая данные по HTTP, вызвав session_id.

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

Никогда не сталкивался с какими-то проблемами при использовании сессий. Повезло или я просто правильно их готовлю?

Мне тоже не смешно, если вы не понимаете, что я говорю о технических преимуществах и смотрите на сессии только в контексте браузер <-> php. Я же смотрю на них в том числе и в контексте php cli, там мне куки как сбоку припёка.

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

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

И сам спор в принципе бессмысленный. Это равносильно холивару использовать фреймворки или нет. Ответ все знают.

Да я в общем-то согласен, и не хотел вступать в дискуссию, но коли начали мои слова по буквам разбирать, не смог удержаться

А что вас не устраивает? Там реализация будет немного другая, но сессия останется сессией.

Представьте такую архитектуру:

DB <-------> Server 2 <-------> AMQP Server <-------> Server 1 <-------> Client

Связь с БД имеет только Server 2, который обрабатывает сообщения, переданные по AMQP протоколу. В целях безопасности с внешним миром он вообще связи не имеет, связь только вот с этим AMQP сервером. Степень доверия к AMQP-серверу низкая. Пользователь может обращаться только к Server 1. И так, внимание вопрос: Как на Server 2 я узнаю, что Client авторизован и где мне хранить временные данные относящиеся к конкретному сеансу и как их очищать при его завершении? Сдается мне, что то, что вы придумаете, будет очень сильно напоминать сессии.

Да. Фишка в том, что авторизовывать можно не только браузер, это может быть любое приложение, которое механизм кук вообще не поддерживает, это может быть Server 3, Server 4 или вообще пользовательские приложения как в социальных сетях. Но даже если на другом конце только браузер, зачем мне гонять туда-сюда какие-то куки, когда достаточно выдать access-token, который будет служить идентификатором сессии и использовать вполне работоспособное, универсальное, а главное готовое решение? Кэш именован этим самым токеном, и может быть легко удален при логауте.