приведите примеры использования двух подходов, если несложно

похоже на std::reference_wrapper…
у Вас появилось копирование, против которого уже негативно высказывались

Предчувствую очередной минус, но для 0serg за его труд и аргументированность отвечу.

1) Цель статьи рассказать про концепт ФП — иммутабельные данные. Про Map, Reduce, Filter, карринг и т.п. много написано, но про иммутабельные данные, которые в ФП являются одним из краеуголных камней, сложно что-то найти. Про операции над списками много статей, а реализации некоторых дают немалый оверхед.

2) ФП в С++ смотрится странно, а некоторые его концепты вызывают недоумение. Но и они находят свое примение.

3) D не мой основной язык, просто в стиле "Практический подход к решению проблем программирования C++" (Автор: Мэтью Уилсон) предложил как можно реализовать immutable.

4) Почему-то все комментарии прочитать про D заминусованы, хотя из D в С++ уже пришли шаблоны с переменным числом аргументов, static_assert. В С++ 17 придет constexpr if. Да, то из D, в адаптированной для С++ форме.
В книге "Язык программирования D" от Александреску очень хорошо написано про иммутабельные данные (глава 8).

5) Теперь по сути. Все стали критиковать недостатки value. А достоинства шаблона Immutable<> как-то ускользнули. К value я вернусь попозже.
Например, использование к указателям.

void foo(Immutable<int*> &a)
{
    int *c = new int(100500);
    Immutable<int*> b(c);
    *a = 0; // error
    a = b; //error
    //...
}

Оверхед от Immutable<> меньше чем от smart pointers. А для компиляторов, которые устраняют лишнее копирование (стандартное требование в С++17), его либо нет, либо очень мал. Потому что, шаблонная обертка выкидывается Gimplifier (это под капотом gcc) в gcc.

6) Почему оставлены модифицирующие функции для value?

• Функция может что-то возвращать что-то интересное для нас (заминусовали);
• Сохранение семантики (заминусовали);
• Некоторый контекст (какая-нибудь библиотека) может потребовать наличия данной функции;
• Некоторые функции в какой-то библиотеке (которую нельзя менять) не меняют объект (явно), но не объявлены константными (разгильдяйство, старый код и т.д.)
• В общем случае эти функции сложно запретить (не будем же нежелательные функции убирать в private и там писать using Class::function). Более подробно расскажу в примере с заместителем:
• нужно сделать класс (защитный заместитель), или еще лучше что-то вроде шаблона optional (C++ 17, см. предложения Страуструпа), который должен быть похож на замещаемый класс. Вот здесь в дело и идет CRTP плюс перегрузка оператора. (за его отсутствие у меня используется ()).
  Если нужны более объемные примеры, то поищу (у меня сейчас делается еще одна статья, плюс готовится цикл статей по написанию собственного компилятора в доступном изложении).

1) иммутабельные данные могут обрабатываться в разных потоках без проблем, за счет меньшего числа побочных эффектов.
2) может. Такое устроит (это из будущей статьи):

QVector<Immutable<int>> imm = {
           Immutable<int>(1),
           Immutable<int>(2),
           Immutable<int>(3),
           Immutable<int>(4),
           Immutable<int>(5),
       };

Stream<decltype(imm)> t(imm);
qDebug() << t.map(static_cast<QString(*)(int, int)>(&QString::number), 2)
            .filter(std::bind(
                        std::logical_not<>(),
                        std::bind(QString::isEmpty, std::placeholders::_1))
                    )
            .map(&QString::length)
            .filter(std::greater<>(), 1)
            .filter(std::bind(
                        std::logical_and<>(),
                        std::bind(std::greater_equal<>(), std::placeholders::_1, 1),
                        std::bind(std::less_equal<>(),    std::placeholders::_1, 100)
                        )
                    )
            .reduce(std::multiplies<>(), 1);

3) в конце статьи упомянуто, что такое не надо делать;
4) манипулируя с адресом можно сделать все что угодно. Даже в Java через механизм рефлексии можно напакостить;
5) меньше побочных эффектов, т.к. работаете с копией.