Здравствуйте, vdimas, Вы писали:
V>Если речь про структурное построение, а не про арифметические или логические вычисления,
Вы зря противопоставляете эти две концепции.

var a = 5;                            var a1 = a + 1;
var d = DateTime.Now();               var d2 = d.AddDays(1);
var l = (new {42}).ToImmutableList(); var l2 = l.Add(1);

Во всех трёх строчках происходит одно и то же — конструируется новое значение на основе старого, старое остаётся неизменным.
То, что первая и вторая строчка = "арифметические операции", а третья — "структурное построение", ещё менее важно, чем различия в синтаксисе между оператором + и вызовом метода.

V>то этим св-вом обладают все языки, в которых можно описывать структуры, кортежи или их аналоги.
Ну конечно же нет. Вовсе не любой язык даст вам возможность сконструировать иммутабельную структуру, кортеж или их аналог по образцу, но с некоторым отличием.
Ну, то есть формально говоря так можно сделать в любом языке, но если в синтаксисе языка нет таких средств, вы просто не захотите писать в таком стиле.
Запись в стиле p.Text = "Hello", которая изменяет значение поля в структуре p, есть примерно везде.
А вот радости писать p1 = new Foo(p.Field1, p.Field2, p.Field3, new Bar(p.Field4.Field1, p.Field4.Field2), p.Field5 + 1, "Hello", p.Field7) — крайне мало.
На С++, наверное, можно что-то намутить через лямбды, которые будут скармливаться "конструктору модификации" — но это опять-таки с необходимостью требует наличия двух различных классов, работающих в тандеме — мутабельная основа и иммутабельная обёртка.

Точно так же неудобно расписывать каждый раз

var tmp = new List<int>(l); tmp.Add(1); var p2 = tmp.ToImmutableList();

Далее — даже если у вас есть синтаксически приемлемый способ конструировать новое значение на основе предыдущего (например, для списка это так в С++), нужна ещё и приемлемая производительность. В этом месте перспектива "да я сейчас напишу однократно универсальный шабонный wrapper для любого mutable типа" начинает растворяться.

V>Например:
V>1. свойство ссылочной прозрачности, т.к. состояние лямбд неизменно, то любые лямбды становятся чистыми ф-иями;
Лямбды и иммутабельность связаны примерно никак. И состояние лямбд может быть мутабельным, и иммутабельность может быть полезна и без лямбд.
Опять — у вас в голове каша, где ортогональные понятия спутаны во что-то одно.
V>2. детерминированность по чтению при доступе из разных потоков.
Слова "по чтению" тут лишние. Детерминированность при доступе из разных потоков при иммутабельности работает всегда.
В частности, ничего не должно мешать одному потоку выполнять list.Add(5), а другому одновременно выполнять list.Remove(0). Детерминированность вполне сохраняется и здесь.

V>(1) даёт возможность не разыменовывать ссылки с целью копирования результата (ссылки а ф-ии в том числе), то бишь отложить вычисления "на потом", а будут однажды вычисленным — заменить ссылку и/или выражение на его значение.
Это утверждение не имеет физического смысла вне контекста лямбд.
V>(2) дает возможность эффективного распараллеливания программ, т.е. без блокировок. Распараллеливания не только по данных, но и вообще по вычислениям.

V>Большинство типов из неймспейса Immutable не представляют практического интереса для программиста, такие как ImmutableArray, ImmutableList, ImmutableQueue и т.д., т.к. в реальных сценариях экономят совсем мало на реализации своих аналогов. Иммутабельные хеш-таблицы из этого неймспейса можно смело сжечь. Более-менее интерес представляют лишь иммутабельный словарь и множество, оба на основе сбалансированного дерева. Единственные, мать его, полезные два типа из всего неймспейса.
.