I am sorry, but I don't have any more detailed information about "audio CD jitter". I can only say that it has not been an issue here or at
www.hydrogenaudio.org which is another forum I regularly visit.
The wiki article in your link may be partially misleading. It may give the impression that "audio CD jitter" somehow affects the overall long term audible quality of the ripped PCM data. In my experience there can't be such a phenomenon with modern hardware when audio data is extracted in the original digital form. The audio quality is either exactly perfect, i.e. unaltered, or the ripped data may contain occasional errors because of read errors. In addition, the article doesn't mention the difference between the so called "burst mode" and "secure mode" rippers at all.
The secure mode in JRiver programs works quite similarly like the secure mode in Exact Audio Copy, which is a well-known dedicated ripper program.
The Secure mode is not intended only for visibly scratched CDs. An audio CD can have more or less damaged sectors that produce clicks or other audible artifacts even though the disc surface looks fine. The secure mode always tries to read the sectors twice. If a certain sector does not produce bit identical results the program does several reread attempts in order to get a reliable result. All reread attempts and their results are logged so that you can check the possible problem passages later. Sometimes even a failed sector does not produce any audible problems.
EDIT
I did some searching and it seems that "jitter correction" is something that is possibly usable with very old drives that don't have the so called "accurate stream" feature. However, I wasn't able to find any detailed technical explanation about "jitter correction".
All modern drives are said to have "accurate stream" and if I have understood correctly the secure mode needs this feature in order to work. Otherwise it could not revisit a given sector because the drive would most likely go to a slightly different sector. The log would be full of errors and the rip would fail.
Perhaps JohnT from JRiver could explain this better. I think he is the developer who designed JRiver's secure ripping system.