It's certainly debatable. This is just my opinion.
In my opinion they are, because any group of types and functions that implements a module signature must be wrapped up into a module that satisfies that signature at the point of use of any value that needs to satisfy that module signature, instead of a type just satisfying the given signature if the correct functions exist to manipulate it, which means in my opinion there's a lot less flexibility and it works more like constructing a new value of a certain type then it does having constrained parametric polymorphism in the way Haskell does. I think this is why although they technically can be used to imitate rust traits or Haskell type classes and allow a function to polymorphically take any type of that satisfies a certain interface, it isn't in practice used like that almost at all, whereas it absolutely is in Rust and Haskell. Witness for instance how both rust and Haskell have a generic type class for iteration that allows you to take anything that is iterable and use the whole module of functions available for iterables on it, so for instance in Rust you can use many of the same methods on a vector and an array and error checking monads, whereas in ocaml, even though something similar is in principle possible, it's almost never done that I've seen, because you have to essentially declare that I type implements a signature and how it does on every point of use where you want to pass a value of that type into a function that requires something with a certain signature. Instead functions are duplicated between modules for different types, like lists and arrays. Maybe that isn't underpowered per se, but it's certainly a practical consideration in the use of first class modules that mitigates a lot of what they are theoretically capable of that seems in my opinion to fall directly out of the conceptual model of using first class modules to do constrained parametric polymorphism, since values then must become modules.
As for the ability to represent the signature of monads — yes both ocaml and Haskell can currently do that while rust cannot, but there is actually currently active work on an RFC that would rectify that. So I suppose overall you might say that rust's type system is currently less powerful then the other two, but I really don't think that will be true over the long run, and it certainly isn't true of necessity, and rust has a type system with a great many benefits in practical power over OCaml's otherwise, in ways I feel impact day to day use more.