That would mitigate the problem indeed. However, since in doing so you change the semantics of the function and you do not speak of using utimes (or utimensat) as the default, another solution would be to deprecate utimes and add utime, say with the following signature:
utime : string -> (float * float) option -> unit
utime : ?a: float -> ?m: float -> string -> unit
with the time being the current time if the argument is not set (this requires to call time if only one of the two optional arguments is present but I think the semantics are less easily forgotten).
The problem with utimes (or more exotic functions like utimensat) is, as usual, portability. We try to rely only on POSIX-standard functions, and anything else needs to be auto-detected by the configure script.
If we make a new function, I'd rather go with your first one (an optional pair of floats) because it sticks with the interface of the underlying system call.
Also, I'm not convinced that the change in semantics is significant enough to warrant polluting the library with a deprecated function.