По моему мнению, эта идея нарушает три принципа: (1) избегать преждевременной оптимизации, (2) принцип наименьшего удивления и (3) слишком тесная связь данных с пользовательским интерфейсом.
Кажется, вы оптимизируете время, но сколько времени? Если отображение рассматриваемой формы требует очень много времени или ресурсов, тогда да, вероятно, неплохо делать то, что вы предлагаете. Но, вообще говоря, шаблон создания окна и его разрушения, когда пользовательский интерфейс больше не требует его отображения, является проверенной временем практикой. Кроме того, когда окно не видно, оно все еще занимает память. И если это окно опирается на такие вещи, как дескрипторы файлов или соединения с базой данных, это потенциальный источник ошибок.
Принцип наименьшего удивления означает, что нужно действовать ожидаемым способами для всех пользователей системы, включая конечных пользователей, сопровождающих и разработчиков. Шаблон, который вы описываете, необычен и поэтому может вызвать больше проблем, чем стоит.
Другая причина, по которой следует избегать этой практики, состоит в том, что она нарушает дух широко используемого шаблона проектирования Model-View-Controller, который отделяет сам объект от задачи отображения или изменения объекта. Есть очень веские причины для использования этого шаблона проектирования, и даже если вы этого не сделаете, философия, лежащая в его основе, является хорошей. Существование объекта обычно не зависит от какого-либо объекта пользовательского интерфейса и, следовательно, должно существовать отдельно от пользовательского интерфейса. Например, объект Customer существует независимо от того, отображается ли окно, относящееся к этому Customer. Слишком плотное связывание данных с объектами пользовательского интерфейса часто приводит к хрупкому, трудно меняемому коду.
Если вы решите реализовать это, я бы посоветовал не создавать слишком много таких скрываемых окон и попытаться свести их к минимуму, и в этом случае код Майкла Буэна кажется элегантным решением проблемы.