Мне кажется, что данный вопрос стоит рассмотреть с точки зрения нескольких позиций:

1. Безопасность относительно исключений. Какой уровень гарантий должен предоставлять данный метод?
   
2. Производительность. Критично ли получить максимально эффективный код или на данном этапе этим можно пожертвовать?
   
3. Оценить проектное решение в свете известных и проверенных практик, например, принципы SOLID
   

Для начала определяемся используются ли вообще исключения в Вашем проекте и если нет, то можно переходить сразу к вопросу о производительности. В противном случае, рассмотрим каждый случай:

int32_t index = sizeof(T) * head;
        (reinterpret_cast<T *>(&buffer[index]))->~T();
        new (&buffer[index]) T(std::forward<Args>(args)...);
        head = (head + 1) % maxSize;

данный вариант не предоставляет даже базовых гарантий (basic exception guarantee), т.к. если конструктор сгенерирует исключение, то мы уже закончили время жизни объекта вызвав деструктор, но не изменятся size и head; а значит мы пришли в невалидное состояние.

int32_t index = sizeof(T) * head;
        (reinterpret_cast<T *>(&buffer[index]))->~T();
        new (&buffer[index]) T(std::forward<Args>(args)...);
        head = (head + 1) % maxSize;

Можем сделать развилку по noexcept для конструктора с помощью SFINAE или if constexpr и в случае, если конструктор является noexcept; то оставить данный код. В противном случае придется уже действовать в зависимости от необходимого уровня гарантий, однако решения будут достаточно громоздкие: в добавок к развилке надо будет ловить исключение, пробрасывать его дальше, при этом восстанавливать объект или уменьшать счетчики и т.п. Более того можно вообще не обеспечить сильную гарантию при определенных условиях. Как видите, это уже сильно осложнило решение.
Теперь к другому варианту:

// Assignment operator
//        (*(reinterpret_cast<T *>(&buffer[sizeof(T) * head]))) = T(std::forward<Args>(args)...);

Здесь ситуация относительно лучше, т.к. проблемы могут быть только на уровне оператора присваивания, что как минимум перекладывает часть ответственности в сторону автора типа T. Однако воспользовавшись решением от Евгений Шатунов можно относительно легко получить достаточно понятный и "чистый" код на уровне сильных гарантий. Также стоит посмотреть в сторону copy and swap идиомы, как близкой к данной проблеме.
По итогу при необходимости строгих гарантий стоит отдать предпочтение варианту с временным объектом.

С точки зрения производительности, если нет необходимости в максимальной оптимизации, то стоит отдать предпочтение более понятному коду. Данный момент уже прекрасно освещен в ответе Евгений Шатунов, поэтому не вижу смысла повторяться. Однако формально если отбросить предположения об оптимизациях, то вариант с реконструированием по месту (деструктор -> конструктор) оптимальней, т.к. гарантировано не требует выделения дополнительных ресурсов от временного объекта и только две операции + нет необходимости в относительно сложном анализе на перемешаемость/копируемость. В случае со swap, мы можем таки попасть на копирование в зависимости от перемещаемости типа T.

И часто забываемый, но крайне важный пункт про проектирование. Здесь нарушен Single responsibility принцип, что возможно и породило этот вопрос. Т.е. у Вас метод по добавлению элемента может удалять/заменять элементы, что должно вызвать вопросы. Более того, вы решили за клиента вашего API (даже если это и Вы сами) как нужно обрабатывать исключительную ситуацию по переполнению. Потом например вы решите, что в одном месте стоит сложить старые элементы в отдельную очередь в другом залогировать или удалять не по одному, а сразу половину буффера. Все это потребует переписывания метода add, а зачем и почему? Попробуйте убрать эту часть кода заменив на выбрасывание исключения или вариант с возвращением успешности операции (менее грамотное решение, но это уже из области субъективной оценки) и посмотреть как увеличится прозрачность и простота написания клиентского кода для этого метода. Еще стоит посмотреть на сходное проектное решение в std::vector и его методе pop_back. Подумайте почему он не возвращает удаленный элемент?

Итого, если важна производительность и не важна работа с исключениями; то разумно выбрать вариант с реконструированием; иначе обмен с временным объектом. Но не стоит забывать всегда про анализ проектного решения и правильную ли Вы проблему вообще решаете.

К сожалению сложно объективно ответить на ваши вопросы т.к. сфера разработки приложений и программирования уже настолько огромна, что включает в себя гигантское количество областей со своей спецификой и в архитектуре и в стеке технологий. Постараюсь кратко изложить свои мысли и прошу считать частным мнением.
Увы, готовых рецептов работающих для всех скорей всего не существует и приходится подбирать индивидуально. Однако очень хорошо, что вы задумались о необходимости расширения своих знаний. По небольшому опыту обучения junior'ов могу порекомендовать вам для начала определиться с областью, куда вы хотите развиваться. Это позволит вам использовать roadmap'ы, например, для machine learning и языку используемому в области вроде python, на котором у вас уже есть опыт. Как только вы освоитесь немного с технологиями и простыми проектами, где как раз набьете шишки и наметится понимание используемых приемов проектирования; можете уже пробовать взять какой-то небольшой опенсорсный проект (желательно с документацией + сообществом, где можно вопросы задать) и попробовать разобраться в его устройстве, идеологии, используемых библиотеках. Попробуйте составить упрощенную схему устройства проекта, затем каждой системы и т.п. В процессе разбора должен появится список вопросов или тем для дальнейшего изучения.
После этого как раз уже можно переходить к серьезной литературе по проектированию и/или просто вписаться в разработку крупного проекта, где вас направят в нужное русло.
Из общих можете прочитать про паттерны проектирования, которые встретятся в любом случае; но вот применять их без хорошей мотивации не торопитесь. Т.к. singleton например, где-то считается уже антипаттерном и про его существование просят забыть.