SML isn't lazy. Humans don't think in terms of lazy evaluation. Even though Haskell is much more popular and has much better tools, MLton will usually compile faster code.
SML allows side effects. Haskell talks about purity, but the presence and reliance on unsafePerformIO shows that purity has limits. The practical answer is to write without side effects then add them to designated parts of the codebase which gets you most of the benefits of purity without all the overhead and headaches for the last 5% of your program.
SML is immutable by default, but allows mutation if needed. Making everything immutable is great for some problems (eg, concurrency), but is generally bad for performance (determining when in-place mutation can occur instead of a new allocation is a hard, branchy problem).
The biggest question is why SML isn't ruling the world. Consider golang vs SML. SML is about as fast, has a similar concurrency model in CML extensions, has a much better type system, and has much more simple syntax (despite being a more powerful syntax). Golang is used because the tooling is very nice, but why did Google choose to pour resources into golang (or even make it in the first place) when a better solution exists? Because familiar beats everything.
In schools where SML is taught as a first language, nobody has problems learning it (compared to imperative languages). A lot of such people I've talked to even prefer the syntax. Most schools teach a language with a C-derived syntax and approach, so those devs learn to prefer that (and usually never even see ML-style syntax). Haskell has issues with popularity because of complexity. SML has issues with popularity because "popularity begets popularity".