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

Что касается описываемого случая, то я бы сделал следующее.
Предложенный способ с caFree судя по описанию задачи не разработчику не подходит. Да и в предложенном способе сложно сказать а нужно ли создавать какую-то форму или нет. А вдруг это какой-то справочник, который уже открыт из другого окна?
Я обычно всегда использую присвоение указателя NIL переменной формы после её уинчтожения. Тогда узнать создавать ли форму перед её вызовом очень просто - пишем

if not assigned(Form1) then Form1:=TForm1.Create(Application);

или через Aplication.CreatForm, это уж кому что больше подходит.

При уничтожении формы получается связка

Form1.Free; Form1:=NIL;

ну и на всякий случай в строке объявления в модуле формы добавляем

var
Form1:TForm1 = NIL;

хотя, вроде как начиная с некоторых версий это делается автоматически, но я не проверял.

Далее, когда запускается таймер на "обрушение форм", то желательно бы сделать что-то типа счётчика, который хранит количество обращений к данной форме за последний цикл таймера. Тогда можно обрушать все формы, у которых это значение ниже определенной величины (либо заданное количество форм с наименьшим значением), а у всех остальных отниамть по единичке. Соответственно, в обработке метода OnActivate или OnShow добавить прибавление единички к этой переменной. Кстати, мне кажется, что для этих целей лучше всего подходит уже существующее поле Tag:integer, которое Borland завела специально для нужд разработчиков.

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

Что каксается многопоточности. Это Вам только кажется, что у Вас один поток. На самом деле обработки потоков сообщений RTL сама запускает новые потоки, плюс я экспериментально в своё время выяснил, что событие OnPaint формы тоже приходит в отдельном потоке. Причём очень возможно, что он создаётся даже не самой программой, а Windows. Очень может быть, что и для обработки сообщения от таймера автоматически создаётся новый поток, как и с OnPaint (опять же, нужно смотерть исходники). Так что использование приведенноё Вами конструкции с BeginWrite и EndWrite вполне уместно.

Во-первых, как сэкономить системные ресурсы.
Начнём стого, что не все компоненты эти самые ресурсы потребляют. Часть компонентов не имеет собственного дескриптора окна, а использует дескриптор окна хозяина, куда он вставлен. Например те же TLabel или TBevel.
То есть, первый шаг - сократить до минимума используемые элементы оформления и разбивки типа TPanel, TGroup и т.п. и вместо них, если нужно красивости, испоьзовать TBevel.

Далее, Вы обмолвились о том, что у вас DataSet'ы лежат на формах, я правильно понял? Мне кажется, что это не правильный подход. DataSet сам по себе системных ресурсов GDI не потребляет, поскольку является невизуальным компонентом. То есть, я бы все DataSet'ы из форм перенёс в соотвествующие дата-модули. Их, в общем-то, для этого и придумали. Тогда время на создание форм резко сократится. По крайней мере я сам стараюсь всегда DataSet'ы держать в отдульных дата-модулях. Если всё правильно написать, то можно их потом использовать в разных программах практически не переписывая код.

aaq
Да, koff4 использует один поток. Но если в тот момент, когда он начал сносить свои формы в системе произойдет переключение процессов в Windows, а для этого там специальный таймер есть, то она вполне может забрав управление запустить новый поток для обработки сообщений, из которого вызвать оконную функцию для формы, у которой уже начат, но не закончен процесс уничтожения. В этом случае всё накрывается медным тазом. :)
Кстати, главное, что делают BeginWrite и EndWrite - блокируют и вновь разрешают переключение процессов/потоков в системе.

Что касается использования ресурсов GDI Word'm, то он их потому практически и не использует, что там в основном ТОЛЬКО ОДНО ОКНО. А всё, что вы видите на экране отображается и обрабатывается ручками через один единственный дескриптор окна. Плюс к тому же, насколько я понимаю, они очень строго придурживаются правила: "создал, поиспользовал, сразу удалил" для всех кистей, перьев и шрифтов. А вот у Borland стратегия другая. В модуле Graphics есть такая вещь, как пул используемых кистей, шрифтов, перьев и других ресурсов GDI. При этом когда идёт прорисовка через Canvas, то сначала ищется подходящий ресурс в этом самом пуле, а если его нет, то он создаётся и там сохраняется на какое-то время. Отсюда вытекает ещё один способ экономии ресурсов GDI - сведение к минимуму используемых в приложении вариантов оформления. Один, два, максимум три шрифта, один-два цвета шрифтов и т.п. То есть, программа не должна выглядеть как взбесившийся светофор или новогодняя ёлка. Да и имхо это более правильно с точки зрения правильного проектирования интерфейса пользователя. У него не должно рябить в глазах. :)

Кстати, надо будет на досуге поковырять исходники модуля Graphics. Возможно, что там можно как-то изменять количество хранимых в пуле ресурсов GDI.

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