AR®Есть необходимость периодически переливать из таблиц в таблицы данные в общем объёме где-то до 100 млн. записей.

В каком случае это будет работать быстрее:
1) таблицы источника и назначения в одной базе

Не достаточно информации. Даже одна и та же таблица может быть размещена в нескольких разных файловых группах (например, если она секционирована, или индексы перенесены на быстрые диски в быстрые файловые группы), которые могут размещаться в разных файлах (а файлы - соответственно на разных дисках, разных контроллерах и т.д.)
AR®2) таблицы источника и назначения в одной базе, но разнесены в разные файлы

Не в файлы, а файловые группы, в которые входят файлы (и не обязательно 1), которые см. выше.
AR®3) таблицы источника и назначения в разных соседних базах

Во всех случаях подразумевается, что всё происходит на одном и том же сервере.
См. предыдущие пункты.

При этом еще не стоит забывать и о быстродействии диска, на котором расположен(ы) файл(ы) лога, т.к. быстродействие вставки, особенно если она не минимально протоколируемая - напрямую зависит от количество операций в секунду (iops), который у вас выдает диск, на котором расположены логи.

Примеры:
1. Данные у вас располагаются на NL-SAS дисках, 7200, в RAID 6. Поверх единого виртуального тома контроллера нарезаны логические диски (созданные в виндовс), по которым вы разбросали файлы, содержащие данные и логи.
В таком случае нет никакой разницы, где, конкретно, на логическом диске, будут лежать логи, данные, на какие файловые группы будет поделена база, будут ли логи лежать на том же диске, что и данные или нет.
Быстродействие будет абсолютно одинаково, и определяться скоростью массива и количеством iops виртуального тома, созданного на контроллере.
2. Данные у вас расположены на логическом диске, расположенном на одном виртуальном томе контроллера, логи расположены на другом логическом диске, расположенном на другом виртуальном томе контроллера, либо на другом контроллере.
Это - оптимальный вариант.
Причем чем менее латентный том, на котором лежат логи - тем быстрее вставка, особенно если это конкурентная вставка в несколько потоков (и особенно - "по записи").
В бд, в которую интенсивно пишут (если нужно выбирать) данные нужно размешать на медленных шпиндельных дисках, а логи - на быстрых ssd, а не наоборот!
Потому что быстродействие изменений в базе напрямую зависит от количества операций в секунду, которую могут выдать диски, на которых лежат логи.

Т.е., прежде чем городить огород с файлами и т.д. - посмотрите на физику, которая под ними лежит.
Например, если у вас подо всё - одна дисковая полка, которая размечена "одним листом", в одно виртуальное пространство, RAID6 или RAID60, а поверх нее вы уже создаете какие то тома, или хуже того, ваши диски - это файлы виртуальной машины на этом большом томе - куда вы не двигайте логи, данные и т.д., вместе или раздельно, боком или раком - разницы не будет ровно никакой.
Разница может возникнуть только если вы получите в свое распоряжение физически разные каналы и физически разные тома (для данных, логов, баз источников, баз приемников).

... физика рулит безоговорочно.

Yasha123alexeyvgКак может быть по другому?

например, базы могут быть в разных моделях восстановления
А какая разница?
Симпл или фулл, транзакция всё равно вначале полностью будет отмечена в логе, а лог только потом будет усечен. Можно выиграть только на авторасширении файла, и то только если бэкап лога не делается вовремя.
А минимально протоколируемые операции - минимально протоколируются что в полной модели, что в простой.