I've worked on several applications where a synchronous round trip to a server (even a fast one) is unacceptable.
Highly interactive UI/UX
A UI that changes and reacts to user input "on the fly". Often, these are designs where a full page refresh (even a fast one) is jarring and undesirable.
Also, the "I don't control all the servers" use case.
I work on a site right now that combines video, slide content, webrtc, web sockets, chat, etc. Many of these services are provided by third parties (Vimeo) for example. These components are presented together to create a unified UX. There is a high level of interactivity between components (for example, the video playing advances the slides).
This is the extreme example of the first bullet point. I have a user interface where a page refresh is unacceptable, but users still anticipate being able to interact with all the content.
Extreme latency connections
It doesn't matter how fast your server is if your connection is slow (or non-existent).
This scenario is less common then it used to be, but there are still classes of applications that need to account for slow and dropped connections.
For example, public health workers that need to go into poorer regions to collect data on, say, disease outbreaks. Such an application may need to use local storage to cache the collected data, and perform syncs with the backend whenever it detects an available internet connection.
You could build such an app native, but if your workers are volunteers, it may be cost prohibitive to support all of their platforms with a native app. In such a scenario, a highly cached web app might be your best means of distribution.
If you can believe that any one of those scenarios is a legitimate case where having a fast server just isn't good enough, then the case for Elm is easy: No runtime exceptions. No
undefined is not a function. No surprises.