Да, опять же зависит от целей.
Ведь есть же стандартный List - на практике свой делать не нужно.

Ну, на фронтенде очень даже нужны ссылки между объектами для разработки приложений чуть сложнее чем туду-список. Вот есть сайт для управления проектами в котором есть такие сущности и связи как юзер у которого может быть много папок а у папки много проектов а у проекта много тасков а у тасков много комментариев. На js это удобно моделировать в виде объектов - есть объект юзер у него есть массив объектов-папок у каждой папки есть массив объектов-проектов у каждого проекта есть массив объектов-тасков и у каждого таска есть массив объектов-комментариев. Как это лучше хранить в elm? И вот юзеру нужно отредактировать какой-то комментарий то имея объект комментария в js достаточно изменить только одно свойство comment.text = 'newText' в то время как в иммутабельных языка нужно будет пересоздавать рекурсивно все родительские структуры состояния и это неудобно. Или более сложная задача - как в элме реализовать динамическую вложенность как например возможность откомментировать другой комментарий (дерево комментариев)?  В js достаточно в объекте comment добавить массив который будет хранить другие объекты comment (а они в свою очередь будут хранить другие) и для изменения достаточно только обновить поле в нужно комменте. Или вот еще - как  узнать имя папки в котором находится комментарий? В элме из-за невозможности обратных ссылок нужно будет хранить айдишники вместо ссылок а сами объекты хранить в словаре и имея комментарий нужно сначала вытащить из глобального словаря по айдишнику комментария таск в нем узнать айдишник проекта и вытащить проект , в нем узнать айдишник папки и снова вытащить объект по айдишнику из словаря, когда в js достаточно пройтись по ссылкам -  comment.task.project.folder.name

Ну так и реальном жс сейчас данные тоже иммутабельно хранятся, будь это какой реакт, и там тоже каждый объект пересоздается

Но и данные я обычно храню в жс не вложено, а нормализовано, хоть зависит от кейса

Да и при нормальной реализации иммутабельных структур как в кложе например пересоздание вообще не проблема

А для Elm есть линзы?

Есть, но не такие удобные, как в хаскеле

ну, их нужно вручную писать, так что они теоретически вообще везде есть

в элме нет тайпклассов, траверсаблов разных, со всем вытекающим

как нельзя?

type Leaf =
    Leaf { node : NodeId
         , children : List Leaf
         , parent : Maybe Leaf
         }

Да, это понятно.

а так, библиотек со всякими хэлперами для линз навалом

http://package.elm-lang.org/packages/arturopala/elm-monocle/latest вот это использовал когда-то

в общем доступе пакеты с графами и бинарными деревьями, никаких проблем с ними нет

Нет, ни в жс ни в реакте не нужно ничего иммутабельно хранить, вот я сейчас разрабатываю на реакте с мобикс сложное приложение с разными сущностями которые образуют глубокое дерево или даже граф (чтобы например комментарий хранил массив других комментарий и каждый комментрий хранил ссылку на  parent - родительский комментарий.) и с таким состоянием намного удобней работать чем с библиотекой вроде редакса который как раз и форсит иммутабельность и приносит кучу неудобств

AST вон всякие ещё

type Leaf =
    Leaf { node : NodeId
         , children : List Leaf
         , parent : Maybe Leaf
         }

Это типы описать можно а вот сами рекорды чтобы они ссылались друг на друга создать нельзя

кто запрещает-то?

ну мобикс это мобикс) В моем же коде нет ни одной мутабельной операции. Это что-то вроде привычки, я так пишу независимо от того, редакс это или нет, фронт это или нет, жс это или нет (ну на го так уже не получается=)

И только потому что мне это удобно и так писать значительно проще, чем искать места, где что-то блин смутировалось и из-за этого где-то вылез баг

Max связанные списки и бинарные деревья в официальной документации в примерах, десятки пакетов Elm с графами и деревьями и вложенными структурами, не пойму откуда появилось допущение о невозможности создания таковых