Basil A. Sidorovно вместо того, чтобы отфутболить на "планы и мониторинг в FB" и на "профилирование JVM" - начинаются общечеловеческие рассуждения о сборке мусора, незакрытых курсорах и т.п. тряхомудии.
Я бы даже понял простое "воспроизведи с отдельным FB-сервером, а потом думай дальше".

1. Профилированием приложения мы и занимаемся. Пока профилированием нас приводит к тому, что медленно выполняется метод executeQuery. Мы предполагаем, что далее запрос попадает к FB и он доступными ему средствами формирует resultset, который доступен далее для нас.

2. Относительно планов запроса. А возможно ли получить план в ходе выполнения приложения через JDBC? Не задумывался на этот счет. Надо посмотреть описание JDBC-драйвера. Но я уже говорил, что один и тот же алгоритм (включающий несколько запросов к БД) выполняется медленно (~1c на запись) в случае если в рамках этого же сеанса JVM прошла загрузка и быстро (~0.04) если загрузка шла в другом сеансе (возможно завершившемся несколько секунд назад). Т.к. тестовые данные одинаковые и классификатор одинаковый, то мы считаем что и запросы должны идти одинаковые. А значит, что велика вероятность что и планы у них будут одинаковые (если конечно статистика по индексам и таблицам к моменту выполнения запроса собралась). Может кстати в статистике собака зарыта?

3. Относительно FB-сервера. К сожалению заказчик просит чтобы приложение переносилось копированием к одной машины на другую, поэтому режим сервера нами не тестировался и не рассматривался вообще в рамках этого приложения. Даже если мы увидим, что в рамках сервера приложение работает быстрее, нам все равно надо добиться приемлимой проивзодительности в режиме Embbeded.