Основная задача любого orm-решения - абстрагировать бизнес-логику от деталей underlying storage. 
И использование orm - не всегда самый производительный путь. Если нужна скорость - следует юзать низкоуровневый jdbc + хранимые процедуры )))
Альтернативные orm-решения в некоторых случаях так же не блещут скоростью (посмотрите на поддержку Hibernate-ом вызова хранимых процедур и batch-update-ов).

Для объективности следует отметить, что в случае entity-бинов можно правильным их использованием производительность очень сильно повысить:

• для bmp можно прикрутить prepared- и callable-стейтменты
• в случае cmp контейнер сам максимально оптимизирует underlying jdbc-вызовы 
• следует использовать session facade с тем, чтобы изменение нескольких свойств нескольких entity-бинов проходило в рамках одной транзакции, что сильно сэкономитколичество синхронизаций с базой
• для cmp контейнер оптимизирует jdbc-вызовы в случае relations
• для любых типов entity очень важно правильно настроить размеры пула и кеша

и это далеко не полный список )))

  Я извиняюсь, с EJB я не очень знаком... Entity-bean'ы обязательно должны быть persistent? И если да, то обязательно ли в БД?

Сервис локатор

Проблема не в еджиби, проблема в том, что данные хранятся в разных машинах(разные физически, разные СУБД, разные JVM - неважно), данные скрепляются из разных сущностей на верхнем уровне. Работа по совмещению двух сущностей - это типичная задача СУБД, которая для этого заточена. Если сделать два локальных CMR бина - они оттранслируют выборки в один СКЛ-запрос - всё быстро.
Если разнести их - тут уж ничего не поделать. Лепить в кучу их будет не СУБД, а логика верхнего уровня после перекачки по сети(в любом случае). Тут уж точно медленно.

Если задача стоит так, что бины должны быть по разным серверам - тогда стоит минимизировать обмен. Если нет - свести вместе.
Если один из бинов - а-ля словарь данных, тогда стоит паковать данные покрупнее, отдавать пользовательскому бину(бинам) и кешировать их там. Ессно, речь о value objects.

да


необязательно.
в случае bmp разработчик сам пишет логику персистенции (в любой источник).
в случае cmp логику персистенции пишет контейнер на базе информации из дескриптора. контейнеры поддерживают генерацию кода для БД, насчет других источников - не встречал.