I've noticed this too, and the obvious reason is that spline track is made up of short straight segments rather than a true continuous curve. That's why some track is "chunky", i.e. 16m segments rather than 2m. You can see the chunkiness in Surveyor. If you pick a track with 16m segments and curve it too tightly, you can see the "corners". Even 2m segments become obvious on too tight a curve.
It's done this way a. to reduce the complexity (which leaves more rendering time for other objects) and b. because computers can't draw true curves (processing time would be too high, so short straight lines are drawn to approximate a curve instead, the fewer, the better).
As the gradient goes uphill or downhill, the track curves up or down. But because curves are straight segments, the transitions between them are "corners" where the angle changes abruptly, and the gradient the HUD "sees" reflects this. Also, the HUD is only updated about once a second, and that's enough time for a train moving fast enough to change gradient angle more than once between updates.
Trainz averages out the change between current gradient value and one or more previous ones, which means the value fluctuates before it settles down. But by then the gradient may have changed again, causing further fluctuation. The only time the value stays steady is after you've been on a constant uphill or downhill gradient (no corners) long enough for the fluctuations to settle down to the true value.
There's nothing anyone can do about it. Games have to strike an acceptable balance between "real-life complexity" (painfully slow and unplayable) and "low complexity" that's calculated to a degree of much lower accuracy sufficient that the game can fool you into thinking it's realistic.
