The only thing holdong sml back in my eyes is somewhat clunky syntax and the module system—which is great at first but quickly becomes tricky once you start having to use functors.
A modern, reimagined sml that keeps its core while adopting some of the nicer syntactic improvements from other langs in the family and improving the module system would be a god send
Modeling such a system at the value level is easy enough, but having it run at compile-time introduces some tricky issues (especially around IO).
The module syntax is certainly clumsy in comparison to the rest of the language, and it's not just the syntax - everything about functor arguments is a bit murky.
I've been reading through the paper and it looks really nice. It seems to rely on dependent records, which I assumed might be the case; but it claims the dependency is "benign" and elaborates-way when translated to System-F (I haven't reached that part yet); so it does seem to have found the right "trick" (i.e. a tractable subset of dependent types which enables modules, without losing too much inference or devolving into a game of prove-the-lemma).
Incidentally, it's also a nice use of "first class types" which isn't (fully) dependently-typed. It irks me when I read blog posts about e.g. Agda or Idris, which describe first-class types (i.e. no stratification, passing types in and out of functions, etc.) but call that "dependent types"; then don't mention the actual "dependent" part (type signatures which bind values to names, which can be referenced "later on" in the type).
MLs are good at representing and manipulating complicated data with intricate invariants (e.g. using algebraic data types for representions, pattern-matching for traversing/manipulating data, abstract/existential types for encapsulation and enforcing interfaces, etc.). In practice this makes it good for handling other languages (after all, "ML" stands for "meta language").
Its original purpose was manipulating mathematical proofs/expressions, and it's still popular for that, e.g. Isabelle's core is written in PolyML, Coq is written in Ocaml, and I think some others like the various HOLs use it too; note that these see a little use in industry for verification (although some famous verification examples, like AMD's FPU verification, used ACL2 which is based on Lisp rather than ML).
Jane Street seem to be heavy users of Ocaml, since they sponsor a lot of work on the compiler and infrastructure.
However, languages like Ocaml and F# are direct descendants of ML, and those languages see wider modern adoption. In this sense ML is kind of equivalent to C, and something like Ocaml is kind of equivalent to C++. Haskell is also in the ML family but its laziness and emphasis on purity keeps it a bit separate from its cousins.
In general, FP sees adoption where correctness is of overriding importance -- e.g., Jane Street's use of Ocaml.
let f (type t) some_arg (module M : Stringable with type t = t) = M.to_string some_arg
val f : 'a -> (module Stringable with type t = 'a) -> string
module type Stringable = sig
val to_string : t -> string
let id x = x
id (module Int)
>Furthermore, path-dependent types allow Scala to unify modules and objects, so that the same language constructs can be used to specify the overall structure of a program as well as its implementation details. The unification of the module and term languages is witnessed by the following comparison with the ML module system: Scala objects correspond to ML modules, classes to functors, and interfaces to signatures [Odersky and Zenger 2005].
If you're going for more sugar, F# might fit the bill. Can handle shebangs, too.
Otherwise, I love SML syntax, and would be curious to see the answer to this, too. I find it refreshingly simple and consistent. Is it that it uses 'let ... in ... end' and such rather than whitespace or brackets?
Those are both tricky, but I think the much bigger deal is that the package ecosystem is about as lush as the parts of Antarctica that are above sea level.
I suspect that the standard getting whacked together before the language really had a chance to mature had the unfortunate effect of stunting its growth.
The MLton implementation of SML -- while not necessarily the best ML to practice on -- is particularly interesting because it's a whole-program optimizing compiler. It has a reputation for producing very compact, efficient machine code. Having said that, Ocaml is still a comparatively simple language -- compared to say, Haskell or C++ -- and its native compiler is well known for turning out decent and very predictable code (predictable in the sense that you can read some source code and have a decent understanding of what kind of machine code it will get compiled into).
If you decide to learn Ocaml first, but want to stick to "essential ML", I would recommend Jason Hickey's "Introduction to Ocaml"  over the more modern "Real World Ocaml" , as the latter book introduces every bell and whistle that Ocaml offers, and has a much more ecosystem-dependent focus (third party libraries, third party tooling, etc.). Still a fine book, but I think it emphasizes advanced Ocaml features a bit too much for an introductory text.
And just FYI, reasonml "is-a" ocaml, so you can also build binaries with the regular compiler back-end - you're not "locked" to targeting js.
The full isomorphism is great. I started with the Reason syntax and when I decided I preferred standard syntax, I just use formatting tools to convert my codebases in O(1) effort.
1: Because of tool maturity, and the ecosystem around the standard syntax specifically. I wanted to be able to run `dune utop`, but getting that working with Reason was a WIP; and then there's syntax extensions... And docs are in the OCaml syntax, except the BS ecosystem, which is conveniently bilingual
Free online course that teaches statically-typed functional programming using SML as a teaching language. Lecture videos are short and to the point. Prof. Dan Grossman is widely recognized as a great lecturer and he gets the ideas across really well.
From there learn OCaml, which is the ML with the widest industry adoption.
SML/NJ is a really nice development environment, and using a different compiler like MLton or Poly/ML for the final compilation forces you to use the more common, standard subset of ML rather than implementation-specific features.