Не надо по-хорошему, и так работает

[Starling]

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

Лучше изменить конструкцию и делать дальше правильно, с меньшими трудозатратами. При этом данный конкретный санузел можно оставить и в таком виде как достопримечательность)

Тоже самое мы имеем и на проектах. Зачастую в условиях ограниченного бюждета приходится принимать решения, которые будут работать только на этом проекте (или полностью аналогичном). Как пример – мне не раз приходилось делать постановки, которые закрывают функционал немедленного получения, так как:
1. Данный функционал в обозримом будущем не будет востребован заказчиком
2. Попытка автоматизировать БП с сохранением этой функциональности приведет к значительному увеличению трудозатрат, которые стоят денег

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

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