в общем-то java не предназначена для создания десктоп приложений. Можно конечно создавать, да и вреймворков на эту тему поболее будет. Но это делается только в очень специфичных случаях (ну или по ошибке - если кто-то вроде вас окажется на месте лица принимающего решения)

вот приложения для мобильных устройст да - пишутся на java и, в последнее время на kotlin (что впрочем практически одно и то-же). Но и там в принципе java не является монополистом похоже вы слышали где-то звон, а о чем он вы не удосужились узнать. Особенно доставляют ваши представления о приличности :)
начнем с того, что сравнивать ORM для Java и JDBC, объявляя последний "приличным", а все остальное не приличным, это как сравнивать автомобили, тепловозы, самолеты и "всякие транспортные средства" с двигателем внутреннего сгорания, добавляя, что кроме этого двигателя ничего приличного нет.

Можно реализовать приложение с доступом к БД (возможно и не одной) используя JDBC? вне всякого сомнения! Точно также как можно взять двигатель внутреннего сгорания, поставить его на какое нибудь шасси, установить колеса, коробку передач... зеркало заднего вида... и перевести груз или пассажиров их точки А в точку Б

Далее (это я исключительно в целях вашего просвещения):
javaEE, это не продукт и не библиотека и даже не фреймворк. Это набор спецификаций (буквально - это набор документов которые описывают ту или иную спецификацию), коих насчитывается что-то в районе сорока штук (число меняетс по мере появления новых версий javaEE). Примерами таких спецификаций являются Servlets, JSP, JSF, EJB, JPA итд. Для тех или иных спецификаций может поставляться "образцовая реализация" (reference implementation), но вообще говоря кто угодно может взять и реализовать эти спецификации, так что на рынке существует множество поставщиков javaEE платформ. Само поняние javaEE платформы подразумевает набор обязательных для реализации спецификаций. В итоге мы имеем множество конкурируюзих между собой платформ (только в первом эшелоне их около десятка) - и все реазизуют заявленную версию стандарта javaEE (не все спецификации, но как минимум обязательные к реализации), плюс обычно некоторое количество проприетарных расширений. Но в целом разработчки который работал с WildFly с минимумом напрягов сможет работать с WebLogic или с Websphere

Spring Framework (и сейчас обычно вкупе с ним используемый Spring Boot) - сам по себе он не является реализацией стандарта javaEE, однако он предоставляет средства которые позволяют построить платформу javaEE. Фактически этот фреймворк является средством эффективной интеграции сторонних библиотек и фрейморков и в этом смысле он не имеет целью разработку в рамках стандарта JavaEE. Более того, в течение последнего десятилетие Spring фактически является альтернативой решениям на базе JavaEE. Причем альтернативой чрезвычайно эффективной - настолько, что сейчас общепринятым мнением является такое, что классические javaEE решения это удел динозавров. Но мы конечно имеем огромное количество унаследованных решений и посему javaEE вполне комфортно себя чуствует, и даже под натиском конкурентов как-то мутировать (в этом смысле сейчас уже у Spring появились новые конкуренты)

Struts.. не знаю где вы про него услышали (и главное когда), но это опять таки не реализация каких либо стандартов javaEE. Это MVC фреймворк, который построен на базе Servlets (не в том смысле, что он реализует эту спецификацию, но в том, что для функционирования ему требуется та или иная реализация спецификации Servlets - причем любая в рамках заявленной поддержки версии). Этот фреймворк чрезвычайно старых и сейчас практически никем не используемый (за искючением случаев поддержки и развития унаследованных решений). Ожнако на рынке масса других MVC фреймворков, но опять-же их популярность сейчас не сильно высока в силу того, что поменялась общепринятая концепция построения архитектур включаюзих в себя фронтенд в том или ином виде - сейчас принято реализовывать логику UI на клиенте а не на сервере (справедливости ради нужно сказать, что современные версии Struts также поддерживают подобные архитектуры но.. поезд уже ушел). Т.е. сегоднящние MVC фреймворки по большей части реализуются (или транспилируются) на JS. Поэтому к слову сказать сегоднящние java разработчики это часто еще и javascript разработчики (а также typescript, dart, clojurescript разработчики итд.)- ну по крайнйе мере сие весьма ценится рынком

"всякие ORM для Java" - здесь немного сложнее - изначально такие фреймворки не явялись реализацией какого либо стандарта (javaEE или какого-то еще). Также как и в случае со Struts и Servlets, ORM framework требует для своей работы ту или иную реализацию JDBC - все равно какую (в рамках декларируемой поддерживаемой версии спецификации), и также как и в случае со Struts и Servlets, ORM framework не является заменой или расширением JDBC. Фактически такие фрейморки предоставляют возможность реализации объектной модели данных с привязкой этой структуре хранения в той или иной СУБД (или сразу нескольких). Любое java приложение которое взаимодействет с БД и при этом не использует какого либо ORM фреймворка имеет в своем составе самопальный фреймворк написанный на коленке, часто без всякого проектирования (при примерно в 150% слвучаев) и почти всегда очень криво, с кучей багов и костылей и низкой производительностью (хотя изначальной целью такого подходя обычно являлется как раз стремление получить выигрыш в производительности). Пожалуй первым [успешным] фреймворком такого рода стал hibernate, который и сейчас не утратил актуальности. Но и у него сейчас масса конкрентов (особенно с учетом NoSQL БД, для который имеются свои ORM). А в числе стандартов javaEE появился JPA, который и реализуется всеми этими фреймворками

Теперь отвечаю на ваш вопрос - что ищ перечисленношл "реально используется в разработке"? Ответ очень прост - ВСЕ (за исключением пожалуй что Struts - просто устаревший фреймворк). А помимо перечисленного еще очень много чего другого используется. Так например, я упоминал, что сейчас у Spring появились конкуренты - это фреймворки вроде Quakrus - взяв все лучшее от Spring они предлагают разработку заточеную под k8s т.е. это фактчиески фреймворк для разработки микросервисов (обычнычные серверные и консольные прилдожений тоже можно разрабатывать, но в этом смысле преимуществ по сравнению со Spring в общем-то никаких). При этом quarkus приложения могут компилироваться в нативный код, так что на выходе мы получаем производительность и скорость запуска приложения не сильно уступающие аналогам написанным на golang. Все прочее - интеграния со сторонними фреймворками и сервисами аналогичто тому, что предлагается Spring (ну не все реализовано, но как минимум заявлено). Конечно Spring тоже в принципе умеет то что делает Quarkus, но для последнего микросервисы это основное под что он заточен, в то время как для Spring это просто возможность реализованная дополнительными средстами

Так что так и живем - бесчисленное количество технологий и вреймворков которых нужно как минимум ориентироваться. Это даже не считая того, что java разработчик как правило имеет смежные специализации, в том числе и в рамках использования друших ЯД (JS, python, kotlin, clojure, scala, etc) Собственно это одна из причин того, что я обычно отговариваю людей среднего и старшего возраста от изучения java (ну может если только в качестве смежной профессии - без отрыва от основной) - помимо собственно java нужно изучать множество вещей, которые непосредственно к ЯП не имеют какого либо отношения. А все что касается java как платформы развивается чрезвычайно бурно - пока вы будете освивать одно, оно устареет и потребуется осваивать что-то другое, причем быстро - старпер здесь будет в роли догоняющего очень долго. собственно и молодой разработчик тоже, но для него это будет нормальным развитием карьеры, в то время как для старпера... он выйдет на уровень квалифицированного специалиста тогда, когда ему уже на покой будет пора... Хотя все зависит от самого человека конечно. Но если бы вот сейчас я выбирал бы специализацию... причем независимо от возраста, я бы java не выбрал - это несмотря на то, что я довольно востребованный, и довольно высокооплачиваемый профессионал, не имеющий каких либо проблем с занятостью даже теоретически. Ну просто потому, что сейчас есть более эффективные пути развития карьеры (и благосостояния соответственно) - дочери например я все объяснил и она в мир Java уже не стремится (хотя поползновения были)