The way I see it, the bottom line is if the pitch isn't changing, the pitch velocity should be zero. Otherwise there's a bug somewhere that's causing the invalid velocity value.
I just did a test right now and yes, it's not behaving logically, which suggests a bug or a weird behavior at least. I'm monitoring the variables with the standard SimvarWatcher from the SDK.
Taking the PMDG 737 as an example, which defaults to a pitch down attitude of about 0.8 degrees when it's at rest on ground. The GSX towbarless tug will raise to -1.2 degrees (which really means up, of course) and during the raise animation, which goes from 0.8 to -1.2 controlled by GSX at every frame, the ROTATION VELOCITY BODY X is floating around 0.04/0.05 m/s while the pitch is slowly going up.
However, and this is the interesting (and worrying) part.
As soon GSX stops the raise animation, I can see the pitch ("PLANE PITCH DEGREES") is perfectly steady at the last value reached, not changing by even the tiniest decimal (which is to be expected, since the ATTITUDE has been frozen before starting to raise the gear), but the ROTATION VELOCITY BODY X starts to INCREASE, from the 0.04/0.05 it was while the pitch changed during the raise, to about 0.25 m/s.
This seems to indicate, while the PLANE PITCH DEGREES surely honors the ATTITUDE FREEZE, and doesn't move at all, the ROTATION VELOCITY BODY X is still being calculated, with no visible effect on the airplane locally, but if that gets transmitted over the network, and you use it to compensate for the lower update rate, it explains why locally everything is fine, but not on the network.
Now, if I add the code to constantly set ROTATION VELOCITY BODY X to 0 during pushback, I can see I'm fighting with the sim, because now the value wobbles between 0.0000 and 0.0003, which is very low, and should be enough to not mess up your prediction calculation but, as soon the airplane stops, so GSX is not constantly resetting the pitch velocity anymore (airplane is still frozen, pitch never changed during the entire time), the ROTATION VELOCITY BODY X starts to go up again, settling to around 0.25 m/s, and it finally settles down to 0 after the airplane has been put back on ground AND Unfrozen.
Find attached the modified code which sets the pitch velocity to 0 at every frame while the airplane is pushed, if this works (at least during the push), we might do this for the entire procedure, for as long the airplane is kept frozen.
Is still not an ideal solution because, I always try to be as economical as possible with Simconnect calls so, while we clearly need to set the airplane position at every frame during the pushback, we stop doing it as soon is not strictly required, to be sure we are not spamming the sim any more data than really required.
Maybe a better way might be finding some way to "signal" (sending a single bit of data) GSX is controlling that airplane and just one another signal when it's done, so you might just disable the use of the Pitch Velocity to derive the pitch value from the low network frame rate. The pitch is surely not changing while the airplane is raised so, it's not a problem if you are updating only 5 times per second something that is known not to change. This will spare GSX from having to set the pitch velocity constantly, at every frame, reducing traffic over Simconnect locally.
In fact, thinking about it, do you even need a signal to begin with? Isn't it simpler and more efficient on your side as well, to NOT apply any lag compensation to the pitch (that is, disregarding the pitch velocity in that case), if the new pitch read from the network hasn't changed between calls?
In any case, let me know if you see some difference with attached file, to be placed in:
\Addon Manager\couatl\GSX\assistanceServices