> Тест написанный по спецификации повышает уверенность в том, что система ведёт себя
> в соответствии с данной спецификацией. Тест написанный разработчиком в рамках test-driven
> development сам становится спецификацией т.к. отражает видение автора и помогает понять
> его код.

Спецификацией так и остаётся текстовое описание дизайнеров железки. Набор же тестов - это видение разработчиков, но никак не дизайнеров.

> Это заблуждение. При должном желании и ресурсах можно эффективно протестировать любую программу
> вне зависимости от того что она делает и как она написана.
> Поместить модули в тестовое ложе для модульного или интеграционного тестирования,

Да, и идеально, если и тестируемый код, и код в реальной работе - один и тот же.

> написать эмулятор железа

В случае, если все участки работы с железными портами уже заранее вынесены в отдельную систему (в микроядро) - эмулятор уже не требуется. Сами тесты могут контроллировать (предоставляя API микроядра) что и как вызывает код.

> Вопрос в том - а нужно ли это? Затраты на тестирование должны
> слихвой покрываться предотвращёнными убытками от найденных багов.

Убытки так или иначе распределены по всей Земле. Их посчитать трудно (хотя можно на примере частной какой-то выборки прикинуть).
В конечном же итоге, вопрос лишь в том: есть ли кто-то, кто озабочен проблемами всех?
Благо, такие есть.