The problem with updating a 16-bit counter with two 8-bit writes while the counter is ticking, is that if the low-order byte performs a turn-around before both bytes are written, then you can get a compiletely different total count than expected.

You are vulerable both when writing high byte before low byte or low byte before high byte, and exactly how vulnerable depends on how many ticks that remains on the low byte, the tick frequency and worst-case time possible between the two writes.

A number of chips has special latch mechanisms where the two 8-bit reads or 8-bit writes are performed to an invisible 16-bit latch to get an atomic access to the hardware timer. The datasheet will in that case mention that, and mention any specific requirements, i.e. that you msy be required to always read and/or write the two bytes in a specific order.

When a read or write is splitted into multiple operations and the timer does not have such a shadow latch, you as developer must figure out if the update can be performed safely with a running timer, or if the timer must be stopped or interrupts possibly disabled.