For me, it felt like a heavier cognitive load to do anything with Elm since it was another abstraction level away from the DOM. The quote "I know this is possible in Javascript, but we chose Elm and it makes it very hard" from the "Why I'm leaving Elm" article (https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#techn...) is something I never said to my boss but still resonates strongly as how I often felt internally frustrated when trying to work with Elm. Some of this might have been because I was very familiar with JavaScript and less familiar with something like Haskell, but I think it's fair to say that most people working on the front end web are likely the same.
For example look at the "simple" counter example... there's a ton going on that doesn't seem intuitive, and even having used Elm professionally I double take looking at lines like "update : Msg -> Model -> Model" or "main = Browser.sandbox { init = init, update = update, view = view }": https://guide.elm-lang.org/architecture/buttons.html
The equivalent React simple counter example (https://reactjs.org/docs/hooks-intro.html) is much more understandable IMO/. Even if you haven't ever used React before, it looks much more like typical HTML and JavaScript. React has plenty of gotchas and is far from perfect, but in terms of getting junior web developers making their first pull requests in our codebases React took way less effort and learning.
Elm isn't dead, it has some dedicated FP fans as users and works fine. It is niche though, and I don't expect that to change.
--
As a side note, it always irked me to see the word "I" in either an Elm error message or the official documentation. In errors it felt overly friendly or personified rather than giving me straight technical info, and in documentation it felt concerning that a single person's opinion might have an overly strong influence and that person might not listen to the broader community on some key issue and prevent progress.