V>То есть, другими словами, при желании сэкономить время на юнит-тестах мы практически [b гарантированно[/b] получаем спагетти-код.

Не понял логики. Каким боком юнит-тесты к рефакторингу? совершенно разные вещи. Есть рефакторинг, после которого не нужны юнит-тесты. И есть увешанные юнит-тестами компоненты, которые раз написаны, отлажены и никогда не рефакторятся.

Причины возникновения спагетти:

а) просто грязное кодирование изначально. Особенно наспех. С подходом "а. фигня. это оставим на потом".
б) отсутствие управления требованиями. Из этого следует вот что: часто возникают моменты, когда требуется сделать какую-то небольшую фичу, причем "вчера". Она и делается. С разведением спагетти, чтоб быстрее.
в) плохая архитектура, не соответствующая требованиям. По сути это то же, что пункт б), только еще хуже — спагетти служит цели _обхода неудачной архитектуры_.

Все это совершенно реальная практика.

V>Ибо в режиме экономии времени и отсутствия юнит-тестов рефакторинг невозможен в принципе (точнее он возможен, то тогда об экономии времени придется забыть).

Ну да. Он становится возможен, когда возникает некое временное послабление в жесткости сроков.

V>А спагетти — это такая штука, которая имеет свойство накапливаться, проявляя при этом кумулятивный эффект.

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

То есть сложность задачи по рефакторингу и устранению макарон растет медленно.

V>экономия на юнит тестах (и, как следствие, на рефакторинге)

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

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

Если возможно переписать заново — то возможен и рефакторинг, причем он всегда будет проще.