WPF используют там, где нужно красиво отобразить что-то, а для обычных ПО WinForms выши крыши

Не только красиво, а вообще любое, что отходит от стандартной поставки контролов. На формах, блин, даже специальный листбокс с чекбоксами есть. Т.е. два разных компонента - обычный листбокс и с чекбоксами.

Челы из вчерашней конторы хотят кастомные компоненты. Чтобы в details была, скажем, картинка, слева название таким шрифтом, справа - колонка с рамочкой. Где в стандартной поставке форм такие настраиваемые компоненты, для которых ещё кучу кода и руками написанные классы байндингов не требуются? А если в каком-нибудь DevExpress делать - так это не формы, а именно DevExpress. Т.е. считай другой UI-фреймворк на базе форм или WPF. Там свои байндинги, скорее всего своя система событий и вообще нужно опыт нарабатывать считай заново.

Ещё они хотят, чтобы всё по SOLID и DRY было. А как без MVVM писать на формах по этим паттернам, если там изначально всё заточено на размещение кода в обработчиках событий? Любая прикрутка MVVM будет выглядеть костылями. Ну или пишешь свой фреймворк (в свободное от работы время, ага), либо юзаешь тот же DevExpress со своей реализацией MVVM. Но тогда в чём суть задания на формах? Если они меня возьмут, я всё равно буду у них с нуля изучать DevExpress.

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

Задание было вовсе не для каких-то жутко ограниченных в железе терминалов, хотя WPF запускается и летает на чём угодно - хоть на железе 10-летней давности. Судя по заданию, обычная прилохужа для внутренних нужд больницы или праксиса - т.е. будет крутиться на обычных десктопах и ноутах.

Жалобы на потребляемую память и скорость WPF были лет 10 назад и больше. Знаете, если люди уже давно жрут в обе щеки Электрон, то к WPF вообще претензий быть не должно. ))

Я в упор не вижу, где нужны обязательно формы вместо WPF, кроме каких-то древних проектов, где всё было на формах. И при этом захостить WPF-компонент на этих формах тоже почему-то нельзя. Потому что проект на формах на .NET 2.0?

Вобщем, я уже говорил, что людям, похоже, нужны готовые челы, уже заточенные под их работу. Если они не готовы, чтобы к ним пришёл незаточенный и месяц-два-три изучал их стек и проблемы, то шанс найти даже на 80% совпадающего минимален. Тем более формы - уже давно абсолютно нерелевантный и неконкурентоспособный опыт. Чел у них поработает с формами, выйдет и нафиг никому не нужен будет. Т.к. WPF это XAML, и новый MAUI будет XAML-подобный. И на Андроиде и iOS тоже подобные же UI-фреймворки с разметкой и байндингами из коробки. Т.е. к ним должен прийти заточенный чел, который будет согласен себя похоронить для рынка, лишь бы они своё старьё и дальше дёшево поддерживали.