I just started tweaking with it for last couple weeks, the youtube tutorials/videos all mention something along the lines of "how minecraft tick system works, it works unpredictably etc..."

From my own testing I also found that sometimes kinda in a deterministic way, pearls timing gets 1 or 2 tick delayed. For example If I set a chain of 12 endergenic in clockwise all in "1 tick" distance from each other, send charging and firing pulse in sequence (n + charge pulse + wait + fire pulse), where n is 0 to 11, at 10th or 11th endergenic, pearl arrives at 11 or 12 instead 10. I've look at the codes of EndergenicTileEntity of both 1.12 and 1.16, and I don't see any deliberate randomness introduced inside, So I'm kinda at a loss at what exactly causes this?

The pearl works by distance in ticks, and all endergenic are in 1 tick distance, so why some endergenic that are in sequence are getting their timings delayed?

Unless the mystery is inside mcjty.lib.tileentity, I don't see anything, can anyone help me understand it?

This has to do with the (semi) random order in which tile entities in a chunk tick. i.e. if you have some endergenics and then other logic blocks then you can't know in which order these will tick. So the logic blocks may tick before the endergenics or after it. Or even in between. RFTools tries to work around that by sorting the ticks for blocks it knows but if there are other things in there (like vanilla redstone) that might still fail

Makes sense. AFAIK vanilla redstone block gets "executed" when they get block update, but in rftools all logic blocks are tile entities and they are checking for redstone level inside their tick function.
I had redstone dust inside my timing circuit, as its kinda impossible to do 90deg turns and other stuff with "redstone wire" block.
I'll try making whole timing sequence with only rftools blocks and see what happens.
(also in 1.16 top always shows rf lost as 0 even if its in holding mode for some time (probably), I need to test this further, will open a new issue if there's really a bug)

Edit: Supplementary question: TickOrderHandler is only keeping track of some of the blocks, not wire, redstone transmitter/receiver and other logic blocks, so using them will also introduce unexpected behavior right? Also IIRC ticking order first depends on block placement order, then after a serialization/deserialization cycle (load save) it gets changed. So thats another issue.....