Как смириться с тем, что нельзя убирать плохой код на проекте?

Забить и получать бабос

Смириться. Рефакторинг редко входит в roadmap проектов у организаций и причин этому несколько:
- работает не трогай (сломаешь еще чинить придется)
- зачем платить за тот же результат (редко кто кроме разработчиков понимает зачем нужен рефакторинг)

Если смириться не получается:
- сделай оценку изменений
- составь списк плюсов и рисков этого мероприятия
- выстави это принимающим решения людям в организации

Если все грамотно сделать и расходы соизмеримые для бизнеса, а плюсов достаточно то идею поддержат. Если нет то см.п.1

Сделать презентацию для бизнес-руководства, нарисовать в начале большую страшную проблему и графики роста стоимости поддержки и обслуживания, падения конверсии и тд. Дальше слайды с перечислением пользы рефакторинга. Например - внедрение новых фич сократится по времени и себестоимости на X и Y, изменения существующих фич - на 5X и 5Y. Себестоимость поддержки и развития проекта понизится в X раз, себестоимость тестирования снизится на Y. Нагрузка и расходы на сервера снизятся на X, скорость загрузки страниц увеличится на Y, показатели Bounce Rate снизятся до Z, конверсия вырастет минимум на X и тд и тп. Хорошо, если презентацию вместе с бизнесом будет смотреть маркетинг - для них такие штуки важны тоже. Бизнес понимает конкретные цифры, говнокод как философский концепт - не понимает.

Ну и главное - презентация должна содержать конкретное предложение. Что-то типа "на рефакторинг понадобится Min-Max часов, но чтобы не останавливать работу, мы его делаем параллельно на 3м приоритете после баг/секюрити фиксов и критических новых фич, выделяя на это X часов в неделю."

ЛПР должен понимать, что бизнесу это в итоге будет выгодно а на текущие задачи это заметно не повлияет.

зы: это конечно все слегка преувеличено для наглядности, но суть думаю понятна.

Уволиться

Часто и много демонстрировать к фронтендерам пренебрежение, по случаю делать снисходительные заявления типа "Ну ничего, когда-нибудь и вы станете настоящими программистами" и "Да я понимаю, не всем дано". На любые возражения искренне удивляться и спрашивать "А чего вы обижаетесь, у вас же пёстрые логи и говнокод вперемешку со спагетти-кодом." Не факт, что поможет, но хотя бы весело. Главное не перегнуть палку с критикой, она должна выглядит искренне доброжелательной.

Правильный ответ это комбинация уже данных выше ответов (Забить и получать бабос || Уволиться)

Прочитать книжку "эффективная работа с унаследованным кодом" и подумать за счёт чего достигается уверенность в том, что вы ничего не сломаете при рефакторинге.

Если у вас нет чего-то из того что ниже постараться это внедрить:
- автоматические тесты
- continuous integration
- code review или парное программирование
- автоматические средства рефакторинга
- статическая проверка (typescript, например)

Начать анализировать статистику по причинам возникновения ошибок - часто она в плохом коде.

При оценке времени на доработку обращать внимание на том время которое возникает из-за плохого кода и на то время которое надо чтобы ответственно протестировать изменения вручную.

Постараться убедить руководство внедрить автоматическое тестирование, основываясь на фактах выше. Внедрять его постепенно, сначала для нового кода, который легко тестировать. Когда все привыкнут к инструментам и начнут писать хорошие тесты, можно покрывать старый код перед изменениями.

Как-то так

Напиши оптимизатор.