We have kinda already added some cases like this so I hope nobody has big objections to it. For example, you'll usually see TS_START_ULZMA/TS_END_ULZMA in between TS_START_COPYRAM/TS_END_COPYRAM so you can differentiate the transfer and decompression components of loading the ramstage.
I don't think there are restrictions for choosing numbers apart from what's already written in code comments in timestamp_serialized.h (e.g. 1000+ is for payloads, 500-1000 is for vendor extensions, in particular 500-600 Chrome OS and 950-1000 Intel). If you're adding timestamps that will always fall between TS_DEVICE_INITIALIZE (60) and TS_DEVICE_DONE (70), it would probably make sense to allocate them from the range in between (e.g. 61, 62). (In general, we should probably try to keep "generic coreboot" timestamps within 0-100 for now so we keep 100-400 free for potential future sections we want to add.)
Otherwise, I'd say feel free to add as many timestamps as you think will add value. You just have to be careful that you don't risk exceeding the available space on any board. I think that's current 84 timestamps for the total boot (shouldn't be too hard to increase if necessary), with additional restrictions for pre-RAM environments and super-early ramstage before CBMEM init.