You're right, this IC is not designed for sub-second time keeping. You have no control over any of the sub-second counters (either for reading or writing). Correction: I have been informed in the comments that writing the seconds register will clear the sub-second counter.
The 32kHz internal clock is used for all timing functions, with a resolution of at best \$\frac{1}{32kHz}\approx 30\mu s\$, and since the beginning of each cycle is utterly out of your control, that's the best precision (30μs) you could hope to achieve.
Even if you knew the latency between the successful receipt of an I2C write command and the actual, physical register write, and you timed the I2C command accordingly, you still wouldn't know the exact current place within a single 30μs cycle.
The RST pin won't help, for the above reason, and because (to the best of my knowledge) it doesn't actually clear any time counter registers.
I suppose the INT pin could be useful in this respect, because it does alert you to the rolling over of the seconds register, which will have some coherent relationship with the 32kHz clock. However, the datasheet doesn't go into enough detail, and you'd have to do a lot of experimentation to find the required "formula". The circuitry and software required to coincide your register updates over I2C with an INT event would be hellish.
Even if you did manage to do all that, the fact that you have no access to the IC's internal sub-second counters means that you can't even read back the time with sub-second precision, and you would have to refer to INT as an indicator. You'd need an additional external 1MHz counter, phase locked somehow to the IC's INT signal to ascertain the elapsed number of microseconds since INT.
It's not just the I2C bus that makes microsecond, or even only millisecond precision impractical; pretty much everything about this IC makes it unsuitable.