LINQ - это удобство прежде всего.
-----
С этим не согласится сложно. Примерно то же заявлялось при выпуске Аксесса - SQL по месту и оптимизация на системном уровне. Оказалось, однако, что задачу, состоящую из более 10-ка форм, сопровождать практически невозможно.
что оно умеет
-----
Помимо этого надо думать об том где и как применять и какой оверхед времени исполнения будет.
Место применения, как Я понимаю, как раз внутри объекта... где, в принципе, не слишком существенно что именно используется.
Ибо как только сие начинает применяться произвольно, то вылазят проблемы где их не надо.
И получется не первое значение, а массив значений.
итератор и срез вещи не взаимозаменяющие друг друга.
-----
Тем хуже. Ибо если возвращается массив, то хотелось бы иметь его во врапированном виде с корректными индексерами. Если этого нет, то итератор более приемлем.
удобнее делать чаще именно в функциональном стиле,
------
Удобнее. Честно говоря - почти все удобнее делать в функциональном стиле. Тем не мение объемы вынуждают работать в ООП с его оверхедом.
с нехилым синтаксическим оверхедом в виде ООП.
-----
Синтаксический оверхед меня беспокоит мало - это всего лишь время работы разработчиков с достаточно невысокой квалификацией. При правильном подходе - изменения трекируются без особых проблем. LINQ же предлагает смешивать Функциональный и Объектный подходы в одном и том же решении, что не есть хорошо по определению. А удержать разработку в одной концепции будет много сложнее, со всеми вытекающими последствиями.
притянуто за уши.
-----
Не совсем - у меня были формы такого размера в VB6.0.
это не только LINQ- запросы к источнику данных
-----
Потому Я и указал - частичная замена SQL to LINQ.
с "запросы в коде = однозначно неправильно" я не согласен
-----
Что проще
- код, в котором идет работа с объектом, без привязки к источнику данных
или
- код, манипулирующий источником данных через объект и напрямую?

С точки зрения сопровождения - зпросы в коде однозначно есть зло.
Другое дело, что для разработки дешевой поделки основную роль играет не сопровождение, а разработка - чем быстрее, тем лучше. Но тут есть возможность (полу)автоматизации...
можно почти один-в-один заменять
-----
Именно об этом Я и писал выше - приложение на VB6.0 и миграция на VB.Net & LINQ. Остается стиль VB-приложения и издержки на его сопровождение. Это выглядит скорее как большой минус для LINQ.
с которой уже никак иначе нельзя удобно работать
-----
А в чем проблемы? Обычный код. Можно наследоваться и перегружать все что душе угодно. Единственное, что дает генерация - работоспособный объект, имеющий определенный набор функциональности. Набор функциональности, вероятно, не самый лучший и не самый широкий, но достаточный для работоспособности приложения. На моей памяти его было достаточно для работы и меняли в нем что-нибудь редко.
при использовании LINQ можно тоже автоматизацию какую-нибубдь придумать
-----
Наконец высказано желание того, что надо бы рассмотреть область применения LINQ.
Я не против LINQ как такового. Даже в определенной мере - ровно на столько, на сколько он не выпадет из ООП - ЗА. Например та же подвыборка для значений меньше 6 - пусть у объекта будет проперть, возвращающая эту подвыборку, и пусть имплементация оной будет сделана на LINQ вместо итератора (там где заменяемо) - я ЗА. НО Я категорически против применения того же LINQ "поверх" объекта, где он, в основном, и будет применяться.
P.S. Тот объект, что у меня генерируется, Я планирую менять - много чего не устраивает...