Причиной закрытия прокси-сервера как можно быстрее является тот факт, что у вас может быть сеанс, который связывает системные ресурсы (netTcpBinding использует сеанс транспортного уровня, wsHttpBinding может использовать сеансы безопасности или сеансы на основе надежности).
Но вы правы - пока клиентский прокси не находится в неисправном состоянии, вы можете полностью использовать его.
Если вы хотите пойти еще дальше и поделиться общей сборкой с контрактами на обслуживание и данные между сервером и клиентом, вы можете разделить создание клиентского прокси на два этапа:
создайте ChannelFactory<IYourServiceContract>
один раз и кешируйте это - это очень дорогая и ресурсоемкая операция; поскольку вам нужно сделать это универсальным, используя ваш контракт на обслуживание (интерфейс), вы должны иметь возможность делиться контрактами между сервером и клиентом
с учетом этой фабрики вы можете создавать свои каналы, используя factory.CreateChannel()
по мере необходимости - эта операция гораздо менее «тяжелая» и может выполняться быстро, многократно
Это одна из возможных оптимизаций, которую вы могли бы рассмотреть - учитывая сценарий, которым вы управляете обоими сторонами коммуникации, и вы можете разделить сборку контракта между сервером и клиентом.