It wasn't mentioned but I saw that path reference to \SQLServerLogShipping_OM and the database being in standby as well.
The switching around recovery is due to avoiding the likelihood of a large undo file. Some large, long running transaction in the log from the primary needing to be rolled back. If you read that post, that really looks like what they were working around - waited until it all catches up or rebuild log shipping. You'd really want to check the size of the undo file and also check what was going on with the primary when the log backup was taken, e.g. index maintenance, things like that. And where the undo file is written to can also cause a problem when it's large. But again, it's usually the size that will tip you off on that. And you will almost always have at least two slow restores in a row as the next one will need to read the undo file and undo to get it to the right point as if there wasn't a with standby done. Not sure if you can see more of that going on if you change the trace flag to 3014, if you see anything with the undo file...another thing to play with.
But this one was a wimpy one. 

Sue