Ну как сказать... Ограничивать данные нужно прежде всего по ширине и "*" при выборе из VBAK дает намного больший прирост, чем дополнительное условие по времени.
Кроме этого, как правило серверов приложений больше, чем серверов БД, поэтому более критичным ресурсом для системы в целом является именно обработка на стороне сервера БД, а не на стороне сервера приложений.

А сколько записей выбралось в первом и во втором случае, если не скерет?

Это точно

В моей практике уже несколько раз были проблемы с программами, которые запоминают дату/время последнего запуска, документа и т.п. Бывали такие шутки, что, во-первых, время создания VBAK/VBAP (VBRK/VBRP) не совпадало. Во-вторых, иногда программа срабатывала в ту же секунду, когда документ был в процессе создания и, соответственно, при последующем запуске программа его уже "не видела" (время создания было на секунду раньше).

Если система не очень busy то, конечно, вероятность этого очень мала. Но если речь идет о системе, где постоянно создается масса документов, да еще они обременены сложными user exits (бывает необходимость), замедляющими создание документa (особенно в часы пиковой нагрузки), то надо принимать это в расчет.

В ответной части это все учтено.
Во-первых, заголовки без деталей или детали без заголовков остаются в буферной таблице до следующей репликации. Дополнительно производится контроль на дублирующиеся/модифицировнные записи (по уникальному ключу).
Во-вторых, следующая репликация указывает не время предыдущей репликации, а локальное время сервера приложений полученное отдельной RFC перед предыдущей репликацией, да еще и уменьшенное на 5 секунд.