Вот на вопрос о корректной передаче и композиции состояний монады и отвечают. Можно, наверное, чисто интуитивно делать это хорошо и правильно. Но когда есть рецепт, почему бы им не воспользоваться?

Потому что монады — это СТРАШНО!!! 😂

Ну вот давайте снова вернемся к компиляторам. Есть известная статья по монадическим комбинаторам парсеров от 96 года: http://eprints.nottingham.ac.uk/237/1/monparsing.pdf
По большому счету это первая статья по данному предмету. И из нее становится понятно,  например, что комбинаторы парсеров существовали задолго до того, как слово "монада" в контексте ФП вообще начало употребляться. Автор называет это "earlier (non-monadic) accounts of combinator parsing". А теперь вчитайтесь, какую именно фундаментальную проблему решает введение монад автором: "the problem of nested tuples can be avoided by adopting a monadic sequencing combinator" ;)

Эх... Это проблема описания и засилия трактовтелей монад в интернетах. Но есть же простые и понятные туториалы.

Не знаю, какие проблемы беспокоили автора статьи в то время, но для меня как пользователя монадические комбинаторы парсеров решают проблему протаскивания руками состояния и, соответственно, проблему запутаться, передать не то состояние и продолжить парсинг с неправильного места.
Чсх. DCG в Prolog решают ту же самую проблему ровно тем же самым методом, потому что все комбинаторы парсеров - монадические - в силу структуры задачи и решения. 🤷‍♀️

Так и вот. Хороший пример применения абстракции монад к конкретной проблеме. Есть множество конструкций самых разных и очень полезных, которые в итоге оказываются монадическими. Взять хотя бы многочлены.

Поэтому монады имеет смысл учитывать при разработке кода.

Можно успешно решать проблему протаскивания руками состояния без монад.

Они то тут как раз необходимостью не являются, потому что никаких особых экзотических действий с потоком выполнения не происходит.

Можно, но, обычно, монады помогают не накосячить.

Это кому как

Ммм. Можно ли рассматривать обе стадии: переход от ast к ir, и переход от ir к конкретному машинному коду в рамках единого комбинаторного подхода?

Ага, я выше как раз DCG упомянул. Рад, что и Вы с ними в таком контексте знакомы :) На мой взгляд, это слишком широкая трактовка монад, но это уже будет, видимо, спор не по существу.

В принципе, тут примерно тот же подход, что и в случае комбинаторов парсеров. Просто мы уже работаем на уровне абстрактного синтаксиса.

В императивных языках и так привыкли без монад разделять или прокидывать стейт куда нужно. Да и do синтакис в таких языках обычно отсутствует и использование монад будет затруднено.

Если хотите, могу в личном сообщении примеры кода показать. Они для будущей статьи :)

Проблема в том, что с тем же успехом прокидывают стейт куда не нужно. 😉

Ну а кто-то не прокидывает

Ну да, некоторые просто не совершают ошибок, молодцы. Жаль, что так мало таких людей...

Просто если в языке и так есть (условно говоря) оператор последовательной композиции двух действий, то зачем изобретать свой?

Монады - это не про синтаксис, а про возвращаемые значения и методы их компоновки. Соблюдение монадных законов, даже тогда, когда, кажется, что не нужно, сильно упрощает жизнь. Весьма существенно.

Ну. Таков мой опыт. Я когда в тупик захожу с кодом в котором появляется куча if-ов, с бэктрэкингом мерзким или с прохрдами по предоставленным пользователем деревьям, меня выручают монады. do-нотация тут и не при чём даже. Дело в том, как корректно абстрагировать шаги вычисления, чтобы они потом компоновались