The internal timestamps are not necessarily monotone because if they were forced to be then if the single clown in front of you set the timestamp incorrectly into the future you'd be forced to do so too.

If you want monotone stamps from the block header timestamps you can post process them to make them monotone. ... if that kind of error would be superior for your purposes. For this discussion probably the best thing to do is ignore any non-monotone timestamps (and maybe the block before them too).

Because the protocol rules don't have any strong incentives for setting the timestamps precisely they're best taken as approximate.

timestamps are submitted by the miner solving the block, so a misconfigured clock could be the culprit, but most often these are attacks against a difficulty adjustment algorithm or re-org scheme where a lot of hashrate is used to overwhelm consensus and assert that their tampered chain is the correct chain.

This is typically used for forcing a block history in smaller networks where it is easier to dominate the hashrate. Zawy12 is a researcher who has put a considerable amount of work into different rolling window hashrate adjustment algorithms to combat this, like LWMA etc.

It's a fun fact that not a lot of people know: These same algorithms are used in heating elements and thermocouples so that the heat level does not 'overshoot' the objective and is able to maintain heat in windy environments or variable temp environments while staying in a certain window.

If you've ever used an e-nail or soldering iron, chances are you've used something that employs this same tech.