So here’s the thing … I hate to be critical with people who clearly put an effort into accessibility (I generally save that for people who can’t even be bothered to try). But …
What you’ve created is not much better than it was before. Yes, you’ve avoided the situation where focus is reset to the top, but you’ve now created a situation where lots of elements in the Tab order are no longer visible.
That’s fine for screenreaders, it wouldn’t make any difference to them, but for sighted keyboard users it means that it now takes 8 Tabs to move through the content, but only 2 of those Tabs are visible.
In practise, you can sometimes get away with the odd 1 or 2 links that are hidden this way, because it only takes 1 or 2 Tabs to get back to something visible (so it tends not to be a big problem with pages that have a single skip link, for example). But in this case, it could take a user up to 6 Tab presses to orientate themselves back onto the visible screen (all the while wondering where tf the focus is!)
So basically, the visually-hidden / offleft approach is not really suitable for elements which are in the Tab order.
I would suggest, for this example, that you go back to the display based implementation, but then you script it so that you’re monitoring exactly where the focus is. If the focus is inside an element that you’re just about to hide (at the point when you hide it), then you programatically move the focus to the next item. To make that robust, the paragraphs themselves should be in the Tab order, so that the focus() command moves focus to the whole paragraph (then it wouldn’t matter if some of the items didn’t have any links in them).
I’d also suggest looking at some ARIA markup to enhance it, probably aria-hidden for each paragraph (true if it’s hidden, false if it’s displayed). And you should provide mechanisms for users to expand the whole thing (so they can see all the items all at once), and to pause the animation (so they don’t have to hurry to read it).