I appreciate the vote of confidence! “Chirurgical Precision” as “very very precise like a surgeon”
The “monitor off” idea is not new with WMR and inside-out tracking because of the cameras looking at the surrounding. If this “surrounding” is moving by itself because it is the image seen on a monitor, it can cause troubles. It is possible the G2 and latest WMR versions are more robust against this though. I’ve tried it out as well with my G2 for the same reasons as yours and it didn’t make much difference in the end to me, but if you’re using a large screen and it is very bright (for the cameras) it is possible it is affecting tracking to some extent.
The only way I’ve found to reducing the G2 tracking jerkiness is reducing settings and/or resolution so that FS2020 is rendering at a higher fps but it is not eliminating it entirely, or to not use the G2 but a solid tracking system which is the Index and the outside-in tracking via the LightHouse 
PS: Given it seems to be happening only with FS2020 I’m wondering whether it is not the same problem as with the camera: FS2020 is breaking the VR golden rule: don’t move the camera, the user is
In other words, FS2020 is trying to "project’ where the camera will be and the accuracy of this projection depends solely on the frame rate and the frame time stamp (clock precision). This is not supposed to be done by the application though because OpenXR API is telling it about these things automatically. I know it is surprising such a basic VR mistake because Jorg is telling us they are doing VR/AR for a long time and they continue to do so, so we must believe him saying so and this can only be a bug.
But in fact the bug might just be in WMR OpenXR. I didn’t pay attention nor tried using SteamVR OpenXR with the G2 to see whether there is the same level of jerkiness, but this might indeed tell whether the problem lies in the WMR OpenXR code or the FS2020 code.