Within these families of languages, I've worked with Guile Scheme, Racket, Haskell, Elm, and Purescript. I've also spent, in pursuit of "enlightenment," a fair amount of time building a (now long abandoned) Lisp-like language based more on my understanding of the lambda calculus and The Seven Laws of Sane Personal Computing than on any established Lisp lineage. These sets of languages seem to me to be distributed along a spectrum of fixedness that may be applicable to any given programming language; these are simply common exemplars.
The power of Lisp-like languages seems to come from their avoidance of any fixed points, so to speak. Lisp was originally created as a research tool for theorizing about and producing a general AI-focused language. It's rooted more in theory than in hardware, and this abstraction grants it some safety, but it's not a goal of the language. It's low-level theory-wise in the same way C is low-level hardware-wise; in both cases this means that the compiler or interpreter can't catch many errors for you ahead of runtime because there really isn't much in the language to help you communicate intent to the compiler or interpreter.
The power of the ML-like languages I've worked with comes from their rich type systems. These allow communicating intent regarding the expected inputs and expected outputs of the program and its functions. These languages are accordingly more verbose than their Lisp counterparts, but in my experience you save a lot in terms of debugging time, especially as your codebase grows.
For my own temperament, Elm has been one of my favorites so far. I have a strong gut reaction to unhandled runtime errors, and I can't shake the feeling that unit tests in languages without expressive type systems may miss edge cases that could have been covered with a stronger type system. The thought of an end user encountering an unhandled (or "diapered") runtime error in production fills me with anxiety. Having to write production code in a language which does not have, for example, a totality checker means experiencing near-constant low-level anxiety because I cannot be confident that, even in unit-tested code, I've not missed something that might result in an unhandled runtime exception and undefined behavior.
Elm was fantastic for my confidence in the quality of the code I was producing. The compiler caught everything. I never encountered an unhandled runtime error, and my strong aversion to the diaper antipattern ensured that the handling was always appropriate. Generally, my development approach was to think about the shape of the data I would be handling, write the appropriate type signatures, and then write functions which solved for those signatures. The compiler was a significant ally in that endeavor, working almost like a proof assistant. I cannot stress enough how much I enjoyed this mode of working, even if I did have to write many more lines of code than I'd have had to write if I'd used something less strict.
All that said, I haven't worked with Elm since 2016 or so, and I realize a lot has changed both within the community and within the language itself since then, so take my opinion on that language in particular with more grains of salt than usual. For what it's worth, my abandonment of it had more to do with the distaste my fellow team members had for Elm's strictness and my subsequent abandonment of Web browser-based applications entirely for the majority of the past eight years. I still remember my time with that language fondly and I don't suppose I'd mind returning to it if I had to go back to doing Javascript-heavy application development.
Meanwhile, I spend most of my time these days working with Guile Scheme. I have been using it to build tools for my own use, so I don't have the anxiety that would otherwise result from the possbility of a user encountering an unhandled runtime error in production. I've also been interested in both the work of The Spritely Networked Communities Institute and Guix System for a while now (and have begun working on Guix System support for the MNT Reform) which both use Guile. I figure spending the extra time in it will aid my ability to understand and eventually participate in those projects.