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

Устройство ввода-вывода представляет собой пятиугольную призму в рост человека, покрытую сенсорными экранами (пять — размер команды в МОБА-играх). Экраны отображают необходимую информацию, при этом ввод (то, что обычно делается клавиатурой и мышью) осуществляется касанием сенсорных перчаток к экрану и(или) костюму. Такой необычный стиль заставит игроков двигаться во время игры, создавая нагрузку на разные группы мышц, костей, хрящей, сердечно-сосудистую систему и т.д. Конечная цель — заменить способ ввода, оказывающий отрицательное воздействие на здоровье, чем-то вроде игры-зарядки.

На картинке изображены:
— вверху — изометрия самой системы ввода и игроки в различных позах в процессе игры
— внизу слева — вариант размещения двух команд — по внешнему и внутреннему периметру
— внизу в центре — альтернативное размещение по внешнему периметру двух призм, разъединенных стеной (при этом призмы связаны между собой, хотя мне кажется, достаточно сетевого кабеля между ними)
— внизу справа — концепт сенсорной перчатки

Смотрим описание метода:
Collect() Forces an immediate garbage collection of all generations

Это то же самое, что и с флагом GCCollectionMode.Forced ( по крайней мере, в текущих версиях CLR)

То, что вызов не срабатывает — плохо, ищите проблему в своем коде.
Финализаторы в любом случае должны отработать по завершению программы

Речь идет не о временных файлах, а о т.н. хендлах — идентификаторах объектов ядра, и о виртуальной памяти

Можно назвать несколько причин:
1. Это хорошая привычка. Не всегда вы пишите программы, которые потребляют мало ресурсов и поэтому можно мусорить где угодно
2. Компонентная архитектура. Сегодня ваш код используется в консольном приложении, а завтра — в высоконагруженном сервисе, где ресурсы можно и нужно освобождать побыстрее
3. Глубокое понимание системы. По моему опыту, программисты, которые не следят за ссылками/указателями/ресурсами поступают так не потому, что знают что-то о механизмах завершения процесса, а потому что просто не способны на это
4. Эстетическая составляющая. У каждой открывающей скобки должна быть закрывающая, а у каждого конструктора — деструктор

Если ваша ОС — Windows, то она в любом случае почистит все после завершения процесса.
Вопрос не в том, чтобы «все почистить», а в том, чтобы писать корректный код, который «убирает за собой».
Финализатор просто помогает найти те объекты, которые не были обернуты в using, например

Это именно трюки, т.к. точное время сборки объекта никто не гарантирует.
Как я уже сказал, ссылка будет потеряна не раньше, чем ее последнее использование. В релизе производятся более агрессивные оптимизации, поэтому ссылка может быть потеряна сразу же (но гарантии никакой нет).
Если вы хотите продлить жизнь ссылки, посмотрите на GC.KeepAlive()

В любом режиме нужно, если вы хотите гарантировать, что ссылки на объект больше нет.
Область видимости переменной temporaryFile — до конца метода, поэтому сохраненная в нем ссылка может существовать на любом промежутке от последнего присваивания до закрывающей фигурной скобки.
Чтоб гарантировать, что ссылки больше нет, необходимо присвоить null или другое значение, таким образом потеряется старое, и сборщик мусора будет вправе удалить такой объект

Это не просьба, а повеление.
Другое дело, что объекты, на которые есть ссылки, не будут собраны, но думаю, это и так понятно.
По поводу не вызывать — действительно, лучше не вызывать в реальном коде. Но мы ведем речь о тестах, здесь немного более широкие рамки допустимого

Игнорировалсь до .NET 2.0
Сейчас исключение в финализаторе прерывает процесс

и кстати, совет с исключением в финализаторе хороший, годный, по крайней мере в дебаге (в релизе лучше все-таки тихо вызвать Dispose)
кажется, встречал подобный совет еще у Рихтера

GC.WaitForPendingFinalizers() у вас не срабатывает, потому что сам объект еще не собран сборщиком мусора.

Правильный код может быть таким:

temporaryFile = null;
GC.Collect();
GC.WaitForPendingFinalizers();

сам по себе ООП-поход — это тоже инструмент
мое возражение больше относится к толкованию ООП как универсального навыка, который могут освоить непрограммисты.
вот вы много таких непрограммистов знаете, которые UML диаграммы рисуют, интерфейсы проектируют, но при этом неспособны код написать?

У кого драконы, тот и прав )

Какая ересь эта ваша книга.
Вообще, научить профессиональных непрограммистов программированию — одна из проклятых задач нашей отрасли. Отсюда все ваши UML, ДРАКОН, SQL, Workflow Foundation, VBA и прочая. Реальность, к сожалению, такова, что без базовых знаний в собственно программировании пользоваться подобными упрощенными и визуальными инструментами не получается. Это так, общее замечание.

По приведенным цитатам и выдержке из книги возникает еще больше вопросов.
>я глубоко убежден, что сначала нужно хорошо освоить процесс объектно-ориентированного мышления, а только потом переходить к изучению конкретного языка программирования или моделирования.
глубоко убежден в обратном. Желание автора представить ООП как единственно возможную концепцию выглядит как минимум странным, как максимум — неактуальным.

В третей главе (доступной в примере) идет вперемешку понятие конструктора, перегрузки операторов, области видимости и разных способов обработки ошибок. Все это приправлено формальными примерами на C#. Я слабо представляю себе человека без опыта программирования, который способен был бы понять при первом прочтении, о чем вообще идет речь в этой главе.

Похоже, именно по таким книжкам учатся «астронавты архитектуры».

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

Энтерпрайзненько, однако

если бы вакансия показалась меня заслуживающей внимания хабра — поставил бы, чесслово )

я вам больше скажу: некоторые делают на этом карьеру, выпуская книжки вроде этой

если по справедливости, они исправились до того, как я опубликовал пост )