What type of reasoning do you apply or problems you find yourself solving when you decide to reach for objects instead?
There the obvious places where you have to use objects in boundary spaces between libraries/languages. For example in F# (another OCaml relative) you will use objects to interoperate with the larger .NET world.
Beyond that, objects are a tool in your tool belt. There are cases where a particular problem makes the most sense in you own head in an object-oriented abstraction, and the idea of a multi-paradigm language is that that is okay and you shouldn't feel like you have to spend the mental effort to refactor it to some other pattern.
This extends out to team development, too. An object-based approach might be easier to document and/or understand by the rest of your team. A team working on the back-end primarily in an OO language like C# might have the easiest time understanding a JS front-end the best if the JS followed more of an object-oriented approach than a functional approach. (JS is definitely multi-paradigm.)
The Python philosophy is "Code is more often read than written" and that tends to be a useful gut check for choosing paradigms/abstractions/tools. Will I (and/or my team) be able to read this tomorrow? Ten years from now?
But truth be told, once I moved to Lisps and FP languages I scarcely bothered to touch them. If you're not handling mutable state at all, then an object that primarily exists to carry mutable state is of limited utility.
I did write an object-like system in Heresy, but I've yet to make much serious use out of it; it was largely an academic exercise.