Вопрос: Какие архитектурные подходы выбрать для разработки клиент-серверной игры?

Лучший ответ: 1) Разделите мир на "чанки", т.е. просто на квадраты конкретного размера. В случае 2д это будет очень удобно.
2) Сервер обрабатывает только те чанки в которых находятся игроки, в случае отсутсвия игрока в нем то он сейвится на винт\бд. На клиенте чанки так же выгружается из памяти если он ушел в новый чанк.
3) Понадобится система пресказания какой чанк надо подгрузить. Скажем зная направления игрока предполагаем что он попадет в такойто то чанк а значит грузим его заранее.
4) Игроку при приближении к чанку отправляй его полное состояние а уже после только то что в нем изменяется.
5) Часть вычислений для линейных(предсказуемых) объектов можно синхронизировать только периодически. К примеру летящий астероид логически обсчитывается и на клиенте и на сервере но только в случае событий(столкновение к примеру) идет синхронизация между клиент-сервером.
На заметку, чем больше линейных(т.е. предсказуемых) объектов тем меньше можно синхронизировать их. Кроме того это сразу же даст бонус в виде достаточно простой реализации интерполяции и экстраполяции.

Худший ответ: так и не осознал, что хранится в БД, а что - в RAM ... автоматические системы кеширования/сброса в БД?
В БД хранится вся информация мира, в текущий момент. Представьте, что сервер внезапно "умер", вся инфа в памяти исчезла, и теперь доступна только та инфа, которая сейчас в БД. Но получить инфу довольно долго, поэтому, используются кэши, иногда - многоуровневые. Если бы БД имела бесконечную скорость работы, то кэш был бы не нужен. Но, к сожалению, кэш необходим. В идеале, в кэше находится вся та же инфа, что и в БД. Но сложнейшая задача - инвалидация кэша (в БД инфа уже изменилась, а в кэше - нет, ещё хуже - в одном кэше тоже изменилась, а в другом - нет). Для того, чтобы потом не собирать баги лопатами, то придётся создавать автоматические системы кеширования/сброса.
Почитайте статьи "Архитектура высоконагруженных приложений. Масштабирование распределенных систем" (части 1 2) от Badoo.Как, собственно, производить синхронизацию клиента и сервера?
Весь мир только на сервере, у клиента нужны только доступные (видимые) игроку объекты, иначе игроки узнают "лишнюю" инфу (например, в World of Tanks есть способы узнать "невидимые" танки). Но, к сожалению, так обычно не получается. Клиенту приходится знать чуть о большем количестве объектов, для того, чтобы прогнозировать их поведение. Но в космических играх попытаться можно сделать видимость объектов. Вы сказали про сенсоры корабля, эта очень хорошая мысль - объект исчез из сенсора, то пусть клиент удаляет этот объект. Если в дальнейшем объект становится в сенсоре, то пусть об этом сервер сообщит клиенту (или не сообщит, например, корабль включил маскировку, тогда клиент вообще не знает, что "кто-то" есть). Это можно добавить в геймдизайн - если объект попадает в зону сенсора, то сенсор увидит не в тот же миг, а через некоторе время, в зависимости от харакетристик сенсора (но не меньше пинга, хе-хе).
Почитайте серию статей "Сетевое программирование для разработчиков игр" (части 1 2 3), а также блог 0fps.net (на английском, нет нормального содержания, но есть сильные статьи). Ещё полезнейшая статья "Борьба с читерами в онлайн-играх: 22 «нужно» и «нельзя»".создавать на клиенте экземпляр той же симуляции мира, что и на сервере
На клиенте создавать серверный мир не нужно, но и полностью отделяться тоже не стоит. Часть кода между сервером и клиентом будет общим. И чем больше, тем легче потом разрабатывать и клиент, и сервер. Помните про наследование с полиморфизмом, про общие проекты в решении. 
Сервер не должен ничего знать про Unity3d, да и клиент игровую логику должен делать без использования инструментов Unity (про это ещё говорит TheShock). Так будет гораздо проще в дальнейшем. может ли что-нибудь дать использование ASP.NET (возможно core) в качестве основы, или для таких целей его использование бессмысленно?
ASP.NET не нужен, имхо, он мало пользы может дать игровому серверу. Я бы начал делать сервер на .NET Core (можно и .NET Framework, просто сложнее будет деплоить. Подумайте про Azure).
Дмитрий Александров предложил про чанки. Мне кажется, что это хорошая мысль. Почитайте статью "Введение в октодеревья", возможно, это решит проблему с длинными расстояниями. Чанки будут нужны, потому что однажды один сервер не сможет "осилить" весь мир, придётся разделять его.