I have the 2 second stutter issue in the original Dirt Rally, which I've tracked down to it polling for new input devices. I suspect it could be the same in Dirt Rally 2.0, which I don't yet own, but I've been keeping a close eye on for VR. I'm using Windows 10 x64 v1903 with a Valve Index HMD and the current SteamVR beta.
I captured a CPU snapshot of the spikes seen in the SteamVR Frame Timing window. That showed the activity was a call to DINPUT8!EnumDevices, which came from drt.exe via the Steam overlay hooks in GameOverlayRenderer.dll. Back in drt.exe it was sleeping for 2000ms and then looping back round to enumerate input devices, presumably to check if any new controllers had been plugged in. Editing the 2 second sleep to 10 second changed the frequency of the CPU spikes in the timing window, confirming it to be the source. Why it stalls everything so badly isn't currently known, but is probably a shared lock somewhere.
Could someone in the development team check if it's the same issue with DR2? Ideally, could that thread only be polling in the menus and when the game is paused? If I get a chance I might knock up a utility to disable the device enumeration a minute after startup.
Edit: For a quick test on the original Dirt Rally I've just hex-edited drt.exe and changed the sequence FF 68 D0 07 00 00 FF to FF 68 D0 07 00 01 FF. That causes it to enumerate devices only once and then sleep for a loooong time. As long as my wheel/pedals/shifter are plugged in when the game is started it's fine, and the game no longer glitches. It may be a different instruction pattern in DR2, and any module changes could trigger anti-cheat protection, so experiment at your own risk!