They were game devs, so they weren't so much interested in how the chip was SUPPOSED to behave, but rather in how it ACTUALLY behaved. If you look at their code, you'll see instructions being used in ways that they weren't intended, or for their hidden side effects.
You saw similar kinds of shenanigans with the 6502 chip and its "hidden opcodes" that eventually became semi-official.
The mere idea of using binary coded decimal to implement a time counter that can trivially be converted to decimal numeric sprite indices is brilliant. If SBCD had operated as described in the manual, it would have been completely inappropriate due to the extra time SBCD takes to run. But since the instruction already alters the status register, there's no need for an additional CMP, and so SBCD is faster overall, and then a simple shift-then-index is wayyyy faster than a full binary-to-decimal conversion when displaying the timer on screen (DIV performance was abysmal on the 68000).
An OS vendor wouldn't do these things, because there'd be no guarantee that a future chip (68010, 68020, 68030 etc) mightn't actually behave as the manual states, and then the code would break.
You saw similar kinds of shenanigans with the 6502 chip and its "hidden opcodes" that eventually became semi-official.
The mere idea of using binary coded decimal to implement a time counter that can trivially be converted to decimal numeric sprite indices is brilliant. If SBCD had operated as described in the manual, it would have been completely inappropriate due to the extra time SBCD takes to run. But since the instruction already alters the status register, there's no need for an additional CMP, and so SBCD is faster overall, and then a simple shift-then-index is wayyyy faster than a full binary-to-decimal conversion when displaying the timer on screen (DIV performance was abysmal on the 68000).
This is how they managed to squeeze so much juice out of the chip, as evidenced in the Metal Slug series, and SNK vs Capcom https://en.wikipedia.org/wiki/SNK_vs._Capcom:_SVC_Chaos
An OS vendor wouldn't do these things, because there'd be no guarantee that a future chip (68010, 68020, 68030 etc) mightn't actually behave as the manual states, and then the code would break.