> Ок, спринг стал мейнстримом. Учту.

По крайней мере, в рунете на Java-конференциях про спринг говорят очень много,
а про Java EE - практически ничего. В других частях света может быть ситуация иная.

> Если ещё Hybernate заменяется чем-то менее монструозным
> - вообще сочту, что чудо случилось.

Есть несколько реализаций интерфейса Java Persistence API,
Hibernate - это только одна из таких реализаций.

Кстати, в презентации https://www.youtube.com/watch?v=YzOTZTt-PR0
рассказывается для каких проектов от Hibernate / JPA будет
больше вреда, чем пользы, начиная с #t=48m15s

Если не ограничивать себя рамками Hibernate
- есть много других способов работы с базой данных,
например, спринговый JdbcTemplate или http://jdbi.org/ или вообще,
голый JDBC, если надо выжать из базы данных максимум производительности:
http://samolisov.blogspot.com/2014/01/dao-jdbc-spring-framew...

> По перегрузке - так не берите неудобные библиотеки.

Иногда библиотеки пишутся своими силами. И если язык не будет ничем
и никак ограничивать полет творческой мысли - там могут написать такого...

Вот например, Perl - очень удобный язык, 5-й версии и особенно 6-й,
ничем и никак программиста не ограничивает. Писать на таком языке очень удобно.
А читать потом написанный код на перле? А ведь там полная свобода самовыражения.

> Арифметику сейчас никто не перегружает без нужды. А вот не дать возможности
> сделать нормальное индексирование или сравнение - это скотство, по-моему.

Это минимализм. Такой же подход, который был применен и при создании UNIX.
Реализовывать только то что необходимо без лишнего синтаксического сахара.

Интерфейс
https://docs.oracle.com/javase/7/docs/api/java/util/Collecti...
или
https://docs.oracle.com/javase/7/docs/api/java/util/Map.html
не выглядит сложным или неудобным.

И если используем метод из интерфейса - можно быть уверенным,
что он делает именно то, что написано в описании интерфейса.

> А вот как будут выглядеть на джаве вычисления
> в 256-битовых целых, буде понадобится - мне и представлять не хочется.

Строить программу и модель прикладной области на таких понятиях,
как "256-битовые целые" - это изначальная ошибка в архитектуре программы.

ООП подразумевает, что будут использоваться более высокоуровневые понятия,
а детали реализации будут скрыты внутри класса и интересны только его разработчикам.