I don't think it's a universal property of functional languages. Haskell is also strongly (excessively) typed, down to the level of modeling computation itself, and it's lazy.
See, when you are defining a Haskell program, you are conceptually creating a tree of thunks that eventually get executed by the GHC runtime. Those thunks are typed, meaning they have typed inputs and outputs, and are either side-effect-free or are defined in a context that controls their side effects (e.g. the IO monad).
So you can change the definition of types willy-nilly and either get a working compiled program or some error output that tells you exactly what is broken or doesn't make sense to GHC's model of your proposed computation. Because computation itself is typed, you have a stronger guarantee that it will work as expected when executed by the GHC runtime. Because side effects are controlled, you are forced by the type checker to handle runtime errors (or crash).
At least that's how I understand it as someone who works with gifted Haskell engineers, but exists very much on the periphery of understanding.
> Because side effects are controlled, you are forced by the type checker to handle runtime errors (or crash).
This is generally true in idiomatic Haskell code, but in fact even pure functions in Haskell can throw runtime exceptions, and you are not forced to handle these.
Bottom has to be a member of every type because functions aren't guaranteed to terminate, so there's no really any way around that within the confines of a general purpose programming language.
That admittedly doesn't entail that Haskell ought to have special functions like 'error' that invite the programmer to explicitly introduce bottom values as a mechanism of signaling errors. However, in the real world, executing any function may raise an exceptional condition at any time (e.g. an out of memory error), regardless of programming language.
More info here: https://wiki.haskell.org/Bottom As bottom is the value of a non-terminating computation and a computation of any type may fail to terminate, bottom must inhabit all types. The same goes for 'error'. Although in real world Haskell code (using GHC) you can trap error values if you really want to, so 'error' isn't in fact indistinguishable from non-termination.
See, when you are defining a Haskell program, you are conceptually creating a tree of thunks that eventually get executed by the GHC runtime. Those thunks are typed, meaning they have typed inputs and outputs, and are either side-effect-free or are defined in a context that controls their side effects (e.g. the IO monad).
So you can change the definition of types willy-nilly and either get a working compiled program or some error output that tells you exactly what is broken or doesn't make sense to GHC's model of your proposed computation. Because computation itself is typed, you have a stronger guarantee that it will work as expected when executed by the GHC runtime. Because side effects are controlled, you are forced by the type checker to handle runtime errors (or crash).
At least that's how I understand it as someone who works with gifted Haskell engineers, but exists very much on the periphery of understanding.