Предлагаю вместо уловок с исходным кодом взять IDE, которая умеет блочно комментить. А это умеют практически все IDE, и даже текстовые редакторы, и даже vim (более того, он умеет «инвертировать» комментарии, что тоже полезно при определённых обстоятельствах).

Но уловка — хорошая :)

Вообще, обычно принято ставить PATH=$PATH:<ваши_пути>.
И, есть небольшое мнение, что такие вещи лучше хранить в отдельном файле, аля ~/.profile, и считывать его, а не напрямую прописывать в bash_*. Зачем — чтобы в других шеллах (ну вдруг они вам понадобятся) считывать ~/.profile, а не копипастить env-переменные в их .rc-фалйы :)

Мне стыдно за вашего Java-разработчика :(
Попросите его объяснить, что он хотел, зачем лёгкому web-серверу, раздающему статику и проксирующему запросы к серверу приложений, сдалась JMS. Не могу представить сценариев.

Для балансировки же — JMS Clustering.

Есть банальная идея — взять virtualenv + pip и с их помощью декларативно указывать зависимости.
То есть нужно хранить не либы, а файлик dependencies.txt с указанием версий библиотек.

Далее, при деплое инициализируется virtualenv, и он качает указанные библиотеки и складывает в venv/lib, что очень удобно.

Всё вышенаписанное в целом верно и правильно.

Замечу еще одну важную вещь. Важно не только, какие поля используются в WHERE-условии, но и какие поля вы выбираете.
Например, если у вас запрос
SELECT t.C FROM `table` t WHERE t.A > <..> AND t.B < <...>
то очевидный вариант для индекса по колонкам (A, B) проиграет менее очевидному варианту по колонкам (A, B, C). Поясню — при наличии индекса (A, B) сначала вам придётся найти по индексу строки, которые удовлетворяют условиям, а потом найти среди данных самой таблицы значение t.C для этих строк. Во втором же случае для вычисления t.C можно будет не идти в таблицу, а взять значение из индекса — такая вещь называется Index Only Scan (хотя, для разных СУБД название может быть разным, конечно). Её умеют MySQL/MSSQL/Oracle вроде бы, и будет уметь PostgreSQL с версии 9.2.

Какова мораль? Во-первых, использовать индексы надо с умом, и необходимо знать, какой индекс лучше и чем.
Во-вторых, всё же вы занимаетесь преждевременной оптимизацией. То есть примерно правильные индексы создать можно, но не факт, что они будут оптимальными для ваших запросов. Выше я привёл пример, когда вроде бы правильный индекс проиграет более специфичному для конкретного запроса индексу. Поэтому, когда БД выйдет на приличные объемы, все сложные/тяжёлые запросы по-хорошему надо будет посмотреть через EXPLAIN.

Ну и в-третьих, успехов вам :)