ИгортанГоспода, возникают вопросы, на которые у вас найдутся ответы быстрее, чем перечитать еще тучу мануалов и форумов. Хотя это никто не отменял.
Заранее извиняюсь за вероятные глупые вопросы))) все мы когда то начинаем...
1. Для взаимодействия с ДБ можно использовать JDBC, Spring, Hibernate. Понятно, что чистый JDBC не в почете. Если мне нужно написать приложение с GUI, клиент сервер. Используются хранимки. Вопрос. Что лучше использовать библиотеки или чистый JDBC.


ОРМ и Хранимки - зло
Точнее.
ОРМ зло - потому что берет все самое худшее из двух моделей (РМД и ОО).
ХП зло - потому что через некоторое время это все превращается в не поддерживаемый кусок Г, который работает по принципу "работает не трогай".

А так. Если у вас очень простая задача, и работа с БД сводится к элементарным CRUD, то берете Spring data jpa и радуетесь жизни. Если сложность начинает возрастать, то берете что-нибудь "попроще", например JdbcTempalte.

В ХП очень желательно никакую сложную БЛ не хранить/реализовывать.
Т.к. система управления версиями и проектом там в зачаточном состоянии (читай нет)


Игортан2. Я понимаю, что придется написать свой класс для коннекта и потом подсовывать ему название хранимки с параметрами и получать обратно рекордсет. Кстати, именно, эти классы, как пример, все называют слоем? Слой взаимодействия с БД?


Нет не надо. Посмотрите в сторону Spring и JdbsTemplate.
Можете почитать про DTO...

Игортан3. Туговато приходится с проектированием (Access-шник я). Выделить необходимые классы. При нормальной БД (нормализация подразумевается), можно ли говорить о том, что структура классов приблизительно соответствует структуре таблиц?
Пример таблиц: ТипыЮзеров - Юзеры. Родит. класс - Юзеры, наследники - по типам юзеров?


Забейте.
Объектная модель и реляционная модель - это разные модели.
Поэтому проектируете модель данных (реляционная модель), объектную модель (ваши классы) и слой DTO, который преобразует одно в другое и обратно.
Учтите, что желательно спроектировать модель данных так, чтобы она практически не менялась.
А вот объектную модель наоборот, надо проектировать так, чтобы учесть что в будущем она будет меняться очень сильно.

Игортан4. Правильно ли я понимаю, что Spring, Hibernate используют, пусть и объектную модель, но подключение к каждой таблице индивидуально? Или там есть возможность сборки строки SQL для получения рекордсета.


Hibernate - пытается скрестить "ужа с ежом".
Когда объектная модель не слишком сложная (CRUD) это работает.
Как только начинается что-то более сложное, то лучше взять что-то менее "интеллектуальное".

Игортан5. Swing. Читал на форумах, что сначала пишется вся работа с данными (показать, обновить и пр.) и только потом строится GUI. Т.е. по сути, потом в форме поднимается нужный класс нужных данных и работаем с ним, так?


По хорошему до Swing должна доходить объектная модель.
А работа с БД должна прятаться где-то в глубоких слоях приложения.

Игортан6. То, что в java книжках называется кучей. Есть ли с ней какое то взаимодействие? Или придется писать свои классы (ArrayList как я понял) для хранения поднятых экземпляров форм (AllForms из Access, если кто то вдруг знает) и уже через него работать с экземплярами форм.


Пока забейте.
Просто помните у JVM есть Garbage Collector, который "тормозит".
Точнее иногда начинает "прибирать мусор", т.е. удалять не используемые объекты.
Поэтому распределение памяти и работа с ней, в первом приближении, можно отдать на откуп JVM.

Игортан7. Будет ли возможность в Swing проекте динамически (в процессе работы приложения) добавлять вкладки (MDI интерфейс) как в главном окне, так и в дочернем. Можно конечно сделать все на простых вкладках (TabbedPane) но хотелось бы масштабируемости.

По идее да...
Но я бы вам посоветовал, посмотреть в сторону web.
Например jsf.

вадяпод разные субд можно свои хранимки написать

Вопрос не в том, что может/не может ХП.
А в том как эту "кучу Г" потом поддерживать.
Для обычных ЯП сейчас наработаны куча инструментов для разработки, поддержки и версионирования кода.
А то что есть на уровне 10-20 летней давности.

К тому же проще/дешевле поменять код на ЯП (java), чем менять код в ХП.

Кроме того структура данных для хранения должна быть как можно более "статична"/неизменяема.
А вот код, наоборот должен меняться часто, в зависимости от потребностей бизнеса.

А чтобы не надо было менять полностью весь код/приложение была придумана микросервисная архитектура.

P.S. А всякие примочки к ORM по автосозданию/изменению БД тоже зло.
Для прототипирования еще норм. Но в продакшене, только тщательно оттестированные скрипты миграции.