This means that the core libraries define the signatures of the functions that an Elm application must implement. (All Elm apps "work the same way" in that sense.) It also means that you never have to mock or stub anything in a test. There are also great implications for performance and maintainability.
Elm compiles to JavaScript and is specific to browser applications, but there's no theoretical reason the same idea couldn't be applied to mobile apps or CLI applications or webservers or anything else. (It's just a lot of work.)
Elm the language is different from JavaScript, Java, Ruby, etc because there is no facility for statements or imperative APIs. It’s restricted in that sense. Frameworks in those languages still have some inversion of control, but there’s nothing stopping you from making a network request in your Celsius/Fahrenheit conversion function. (And over enough time that’s usually what happens, and you have fewer constraints with which to reason about what the code does.)
I can’t speak for languages that are similarly restricted, like Haskell, but my impression is that Elm is different because you don’t have to learn extra rule-bending mechanics to do I/O.
The Elm approach is unique, as far as I know. And while it doesn’t make for a truly all-purpose programming language, it’s a great model for developing libraries and applications on the web. I’m just a bit “surprised” there isn’t a similar thing focused on web servers or IOT or whatever else.