There has been discussion about what the timestamp passed to various callbacks should represent (#347 and #943) from which the consensus was to keep it consistent with the window rAF--as the predicted display/vsync time would be better communicated through the frame. (XRFrame.timing.predictedDisplayTime, for example)

@blairmacintyre last pinged on this issue, but the issue has since been closed, half resolved with only the consistent rAF part.

Though, neither the timestamp passed to the rAF, nor performance.now() are useful for the app to produce smooth animations, here's an attempt at explaining this:

Assume a programatically animated car driving a long a straight road, moving it by 1/90*speed every frame. If a frame drops, our car moves slower, the car is frame-rate dependent, so we use a delta time to the last frame instead: dt*speed means that we now run at some difference (our options are either rAF start timestamp or performance.now) that may be vsync intervals +/- up to one vsync interval, depending how regularly the browser schedules the rAF and whether we are hitting performance targets. This causes noticeable jutter, especially when not on perfect performance (which practially never happens, a frame will be dropped even then).
But effectively we are trying to produce the image for the next Vsync, a time that is pretty well predicted through VR drivers/SDKs already for the most part. We want a time in the future instead of trying to play catch-up with previous frames.

Vsync on the web, if I understand correctly, has been a headache for web games and graphics developers for quite some time now (w3c/html#785), there even are tools to measure how this is still not working well (https://www.vsynctester.com/), and I believe for WebXR it's probablye even more important to get this right, as the jutter is so much more perceivable on VR headsets.

CC @cabanier