Правильный путь - следовать API wordpress и особенностям CMS.
Выкинуть всё из стандартной темы и забить туда свой код - это значит либо обречь тему на гибель после того, как кто-то нажмёт на кнопочку "обновить", либо сделать тему необновляемой. Ну и, соответственно, это не WP-way.
Прежде чем делать что-то с темой, нужно разобраться, делаете вы тему с нуля, или обновляете существующую.
Существующую тему используют, если
а) требуется лишь несколько фиксов - поправить вёрстку, добавить несколько блоков
б) по какой-то причине даже глубокая кастомизация получается проще (быстрее, легче) чем разработка с нуля. Скажем, диз темы похож на то, что вам нужно, вы чуть меняете подвал-шапку, а остальное закидываете через Visual Composer или похожее решение.
В этом случае создаётся дочерняя тема, в которой происходит основная работа. В результате обновление исходной темы совершается относительно безболезненно для вашего кода, а дочерняя тема поддерживается на уровне совместимости с исходной (требует доработок где-то раз в год при активно обновляемой теме).
Если в планах разработка темы с нуля - то, как уже отметили, оптимальным будет взять готовую стартер-тему вроде underscores. Делать тему с нуля имеет смысл, если вы не хотите тащить кучу мусора из существующей темы, или разрабатываете что-то, что плохо встроится в существующие варианты.
Изменяемые блоки делаются или через визуальный редактор (Visual Composer или другие), или через механизм опций, или через плагины вроде ACF. Причём ACF использовать не обязательно, у WP есть интерфейс для произвольных полей.
В плане того, что использоваться - ACF, фреймворки, или ещё что, логика примерно такая:
1. Общие элементы темы вроде лого, копирайта, контактных данных - это опции (свой код для страницы настроек), фреймворки опций (Redux, ACF-про ) или кастомайзер WP. Последнее кажется наиболее правильным и соответствующим развитию WP - там почти рукой подать до визуального редактирования уже.
2. Контент страниц - стандартный интерфейс для произвольных полей, ACF или другие решения. С ACF причём нужно быть аккуратным, он может упереться в ограничения сервера по количеству полей или давать неверные данные (писал бакенд для мобильного приложения через WP REST API и хлебнул лиха от сохранённых через ACF данных, привязанных к таксономиям)
В плане кода - всё, что должно решаться через API, решается через API. wp_enqueue_script/style для скриптов и стилей, wp_head(), wp_footer() в соответствующих местах. Вариантов превратить разработку темы в извращение тут очень много, доводилось видеть много всякого от неопытных разрабочтиков. И какого-то универсального решения всего этого избежать, возможно, просто нет. Кроме как учиться, смотреть гайды и лучшие практики, следить за обновлениями WP и рекомендациями для разработчиков.
