I'm pretty sure the reason there are 255 MOIDs is because the game attains pixel perfect collision by maintaining [at least] three bitmaps: the screen, the buffer, and the collision bitmap, which uses the actor's MOID colours to determine collision.
I think.
BAM.

There really wouldn't be any reason to use a colour for collision detection.

It's far, far more likely that Data decided on 256 as an easy integer that actually works fairly well in most gameplay situations. Having it be exactly one byte just makes sense.

Making the MOID screen + palette was probably an afterthought, more of a debugging system than any specific design choice.

Data has some odd programming habits, but linking the number of objects in his simulation to a color palette is not one of them.

Why would you try to do collision with a bitmap layer, regardless?
afaik (from working with the collision system in-game/.ini, not in-sourcecode) collisions are done using atoms arranged into atomgroups which are compared to the terrain layer and then to other hittable MOs if relevant. I just wish data would make the atomgroups into n-gons rather than discrete atoms. It'd make lores atomgroups a lot more viable, especially for larger sprites, and also make deepgroups almost needless. The ability to define custom atomgroups would also be nice.

Or just convenient.
I insert a fictional recreation. Scene is Data's basement, one late Saturday night. It is raining.
Data: "Hm, now I've got this array of MOIDs, so all of them exist here and then if they go over I'll just explode them... And there's exactly 256 of them, nobody will ever need more than that! 256... Same number as 8 bits of binary could encode... Like the 8 bit palette that the game uses..."
*thunderclap*
Data: "I've got it! When you turn on this "MOID Mode" it'll color code them to the palette!"
And so the palette was linked.
yeah that sucked well blah