За 75 или 60 мкс у Вас успеет потеряться к примеру один байт в UART-е работающем без FIFO на скорости 230400.
Прерывания вообще запрещать не нужно. Вся работа идёт в ISR. Процесс приёма бита:
1.Мастер включает pull down шины; программирует таймер на выдержку 15 мкс; выходит из ISR.
2.Получив прерывание таймера: выключает pull down шины; программирует таймер в режим capture с прерыванием/защёлкиванием значения таймера от фронта сигнала на шине; также программируется таймер на отслеживание таймаута
(на случай если удалённая сторона померла или линия залипла в "pull down"); выходит из ISR.
3.Получив прерывание таймера (таймаут): детектирует состояние ошибки обмена с датчиком - завершает процедуру обмена; выходит из ISR.
4.Получив прерывание таймера (обнаружен фронт на шине): считывает защёлкнутое значение таймера, вычисляет прошедшее время - определяет значение бита, сохраняет его; декрементирует счётчик оставшихся бит, если не 0 - программирует таймер на выдержку интервала времени до начала след. бита согласно требуемой и допустимой скорости обмена по шине; выходит из ISR.
5.Переход к п.1.

Всё! Ни одного запрета прерывания! Тем более на огромные интервалы порядка десятков мкс.
Можно немного упростить алгоритм, если не использовать режим capture таймера, а работать на обычных выдержках с принятием решений по границам состояний бит '0' и '1'. Но правильнее будет с capture.
Алгоритм передачи ещё проще, даже описывать смысла нет.

Еще проще объединить прием и передачу в обмен битом. Потому что прием ничем не отличается от передачи единицы.

Есть множество проектов, где запрещение прерываний на десятки мкс не является критичным. Тогда можно делать чисто программную реализуцию 1-Wire, которая намного проще для понимания, чем вариант с таймером.

Здесь раздел для начинающих. Т.е. - для тех кто должен учиться. Учиться делать правильно. Чтобы это потом можно было использовать в других проектах, наращивать функциональность проектов добавляя новые интерфейсы например и функции.
Да и опыта надо набираться начинающим. Как раз вот на таких примитивных интерфейсах это и можно делать.
Я считаю - если сейчас он делает тяп-ляп, лишь бы кое-как, то и потом с него толка не будет.

Можно получить четкое определение "правильно" ?
Вот у меня, например, похожий термометр был прикручен к pic12 и все микросекундные тайминги для обмена сделаны на задержках... Просто потому что не имело смысла возюкаться с таймерами и прерываниями.. Это правильно или неправильно ?

В самом общем смысле: найти такой подход, который максимизирует полезный результат.

Теперь частности: я занимаюсь фрилансом; для меня скорость и качество работ прямопропорциональны денежному вознаграждению,
которое, в отличии от наемных работников, не ограничено сверху. Если я один раз напрягусь, сделаю качественную библиотеку для
работы с DS18B20 и буду многократно без какой-либо головной боли использовать в проектах, то это позволит сократить сроки реализации
проекта и максимизировать доход. Поэтому в моем случае "правильно" - это когда библиотека написана правильно.

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

В pic12 это конечно менее критично, так как ресурсы там сильно ограничены и каких-то серьёзных задач на нём не будет. И дальнейшего серьёзного развития проекта.
Хотя я всё равно, в любом случае, стараюсь делать правильно, т.е. - с минимальным расходованием ресурсов, а не "лишь-бы хоть как заработало".
Описанным выше образом я реализовывал похожий интерфейс на MSP430, где ресурсов много меньше чем на Cortex-M.

Самый простой способ работать с 1-wire через UART . Единственное , что там надо учесть - двойную буферизацию передатчика , если работать по UDRE и с прерываниями + кварц.