Пара замечаний и предложений по вашей проблеме:
1) в классе Configuration имеется несколько перегруженных методов:

Как видите, Вам никто не мешает использовать конфигурационный файл, который лежит где угодно, и использовать его в каком угодно числе приложений.

2) Фраза о том, что Вы пишите ряд web-приложений, наталкивает на мысль, что возможно Вам стоит вынести «слой доступа к данным» (который использует hibernate) в отдельное единственное приложение, и использовать из всех web-приложений этот «слой доступа к данным». Ну, собственно так, как Вы и собирались сделать. И это, по-моему, вполне надежное и правильное с архитектурной точки зрения решение. Ну а детали реализации надо прорабатывать, т.е. как и что разложить по jar-ам и war-ам не могу конкретно сказать.

автордействительно лучше всего вынести все конфиги хибернейта, а также все persistence-классы, на которые мапится база, в отдельный jar, и положить этот jar в classpath аппликейшн сервера.

Правильным ли будет такое решение?

Хороший вопрос… Лично я считаю, что класть свои библиотеки в класспас аппликэйшн-сервера не очень хорошая идея (особенно если речь идет о common/lib). С другой стороны если библиотека используется несколькими web-приложениями то там ей самое место

авторИ еще вопрос, который в связи с этим возникает. Если у меня persistence-классы будут вынесены в отдельный jar-файл, правильно ли будет включать бизнес-логику в эти persistence-классы?

Тоже интересный вопрос. Не вдаваясь в схоластику по поводу того, что есть бизнес-логика, можно сказать, что общую для всех web-приложений логику тоже надо выносить отдельно, ну а специфичную, я думаю, можно и оставить в конкретном web-приложении. Помещать ли общую логику в персистентные классы? Нет, наверное.
Я бы в Вашем случае два jar-а сделал бы и поместил бы их (ну например в common/lib тот же):

xyz-data.jar – здесь хибернэйт утилс, персистентые классы, маппинги, конфигурации и пр.
xyz-logic.jar – здесь общая для всех приложений бизнес-логика

Ну и постарался бы чтобы конкретное web-приложение работало только с xyz-logic, а xyz-data.jar только бы из этого xyz-logic.jar использовалось.

Изложил только свое личное мнение. Может и не прав. Думаю, что у другим могут быть другие мнения по этому поводу… Может кто еще выскажется?

авторХорошо. Пускай у нас есть persistence-класс Client. Зачем мне создавать еще один класс ClientLogic, когда и логику, и данные клиента можно объединить в одном классе?

Надо понять, какую логику Вы хотите зашить в класс Client, и тогда надо разбираться.
Обычно, я persistent-класс Client оставляю чистым бином (с минимумом кода). А для работы с ним создаю какой-нибудь ClientManager (бизнес-логика), который может быть вынесен отдельно. Как правило этот класс ClientManager за время проекта довольно сильно распухает (но конечно интерфейс можно, и даже нужно общий для всех менеджеров сохранить).
Вот как-то так я это понимаю. Но могу ошибаться, конечно.