Это не главная мотивация монад сегодня. Позвольте пояснить. Изначально в Хаскеле

был странный и неудобный способ делать эффекты. Все из-за него страдали, и он ощущался как костыль. Потом пришел Вадлер и товарищи, и они придумали, что тут очень подходит концепция монад из некоей математической теории. Попробовали применить, - пришлось переосмыслить, что есть чистое и нечистое в Haskell. Придумали "RealWorld" как некое немутабельное состояние, над которым эта монада (IO) бы работала. Потом придумали do-нотацию, чтобы сократить запись.

А потом началось. Люди поняли, что монады - гораздо более полезный инструмент, чем просто обслуживать цепочку вычислений с эффектами ввода-вывода. Оказалось, что они эффективно выражают различные концепции, такие как состояние, а do-нотация еще и делает код кристально чистым. И монады стали ценны не потому, что они закрывают какую-то там дыру в дизайне Haskell, а потому, что являются мощной абстракцией, паттерном если хотите, который упрощает код в разы. Так, с их помощью можно избавиться от callback hell, можно сделать асинхронные вычисления не хуже, чем с async / await, которые в других языках являются частью синтаксиса. Можно хэндлить ошибки в цепочке операций (Either; в C++ это std::expected), можно явно выражать отсутствующее значение (Maybe; в С++ это std::optional), и тоже связывать операции-возможно-без-значения в цепочку, не перегружая код. А в последствии еще увидели, что с помощью монад можно делать полный аналог Dependency Injection. И нет, иметь переменные - это не мотивация для монад в Haskell.

Зачем это в С++? По тем же причинам. С помощью монад упрощается код, который ранее мы бы писали очень развесисто. Посмотрите, например, на Go-шников с их вездесущей проверкой результата на err. И хотя в С++ есть исключения, возврат ошибок все же используется, и вот такой код может быть значительно упрощен для чтения и понимания с помощью монады. С помощью монад можно писать более надежный и предсказуемый код. Там, где обычный набор инструкций позволяет допустить ошибку по невнимательности, например, программист не обработал результат функции, монадический код это не позволит. Просто потому, что проверка результата функции будет вшита в конкретную монаду (std::optional, std::expected), и потому "пройти мимо" уже будет нельзя.

Или взять std::future. С помощью монадического связывания очень легко пишется такой код, где таски будут вычисляться либо одна за одной, либо параллельно: программист, оперируя монадическими функциями, выбирает, что ему нужно. При этом ему не нужно специально писать, какую фьючу когда надо дождаться, где синхронизоваться и куда передать дальше. Он просто пишет монадический код, а соответствующая монада возьмет эти манипуляции на себя и сделает их "в бэкграунде". Это очень удобно, так как по сути, программист лишь работает со своей вычислительной моделью, которая не "загрязнена" деталями от std::future.

На дворе 2018 год. Без монад уже нельзя, потому что более мощной и полезной абстракции еще не рождалось за последнее двадцать лет.

↑ tldr: он расписал то же самое, что я и, но подробнее и с примерами :)

даже в 2018 в эмбеддеде и системном программировании обходятся без монад, скорее всего есть какая-то причина, абстракция не всегда хорошо