I figured it was a safe assumption that TIM could do with its own PB's custom data as it wished, and in theory I'd eventually like to support additional definitions there (such as for modded items).

What problem did it cause you for TIM to erase and rewrite it's own custom data?

I use a programmable block to call all other programmable blocks. The custom data stores parameters like recurrence and the slot in which a PB is executed (enables load balance) as well as arguments passed to reset the script or in case the script needs one for its cyclic execution.
I've been planning to call TIM every 30 ticks but currently I still call it once per second.

I think for the time being my stance is that a script ought to be able to assume that it can safely use the Custom Data field of it's own Programmable Block; if your scheduling script requires the use of the Custom Data field on every other Programmable Block, that seems to me like a problematic design which is bound to run into issues with any number of other scripst that also want to make use of Custom Data.

Hence this routine posted above. It adds or overwrites only the info the script needs without changing the other entries. But I gave up the scheduler because the only advantage is load balancing and that's not necessary in most cases and can be achieved in a different way. No need to waste a PB for this and no need for this routine to be implemented in TIM, especially since it's at the character limit.

Anyways being able to use the custom data of a block by several scripts is clearly an advantage. I already do this but with several of my own scripts. Nonetheless they are tolerant for other entries in the custom data.
But in case of scripts being at the character limit like TIM I agree that there are more important features than to share the Custom Data of its own PB.