The base iterator on the server side implements a seek fence, so you can't seek outside of the underlying source anyway. So, it's safe to seek ahead as much as you want until you exhaust the source (reach null top key).
A BatchScanner with a single range will also break things up internally into multiple smaller ranges if they are spread across different tablets. You only really need to compute your own separate ranges in this case if you have large known gaps you don't want to bother with. On the other hand, you may not care about going through these unnecessary ranges if they typically seek straight to the end, because the next computed key is outside the scope of that tablet.
It is hard to optimize this problem. There is no easy answer. I would suggest experimentation, based on your data, to determine the optimal case. It's basically a trade-off between seeks and pre-computing ranges to run in parallel.
Another optimization you can try: instead of always seeking to the computed next, you can advance internally inside your iterator by calling its source's next method a few times. If you don't reach the next element that you would have seek'd to in some reasonable number of iterations, you can then seek. This also is a strategy that is hard to optimize: Do I need to advance, on average 3 or 20 or 10000000 keys? How many before it would have been more efficient to just seek? There's no easy answer. Experimentation helps.