"Глубина наследования" и "сложность иерархии" - вещи сугубо "попиндикулярные". В контексте запечатанных (sealed) классов - особенно.

Т.е. чуть менее, чем все разработчики API. Java SE API - в том числе.

P.S.
Когда же вы все научитесь спокойно относиться к фичами и возможностям, которые не нужны лично вам ?..

Ровно то, что было сказано ещё в античное время: "Богу - богово, а кесарю - кесарево".
Для платформы, которая "бегает везде" нет смысла тянуть в язык фичу, доступную "почти нигде". Сначала - более-менее массовое внедрение и уже потом - поддержка платформы.
При этом, что характерно, никто не мешает сделать так, как вам хочется - собственно JVM требует для своей работы всего пяти классов. Всё остальное вы можете переделать. Если не создавать собственный компилятор - кое-что придётся оставить как есть.

Закрыть реализацию.
Исторический пример - "Sealed: true" в манифесте jar-файла.
Зачем может быть нужно?
В java-классе доступ по умолчанию "в пределах пакета". Предположим, что я реализовал некий "чувствительный" класс, который используется другими классами в том же пакете. Работа с лицензиями или что-нибудь этакое. Наследоваться от такого класса бессмысленно - "важные" методы и переменные не имеют модификаторов доступа, а значит и у наследников не будет доступа "куда не надо".
Но, если "чужак" поместит в этот пакет собственный класс, то сможет получить "некие преференции", которых разработчик трудолюбиво его лишал. Просто создаём собственный класс в пакете разработчика, кладём его "рядышком" и - всё. "Взлом" делается на уровне скрипта запуска.
Если jar "запечатан", то классы любых его пакетов будут загружаться строго из одного места, а значит не будет работать или класс "взломщика" или класс разработчика.
Понятное дело, что такая "защита" тривиально обходится переупаковкой jar-файла, но во многих случаях и такой вариант "защиты" более чем достаточен.

Аналогично и с запечатанными классами. Есть интерфейс (абстрактный класс), который должен быть реализован (расширен) только разработчиком и никем кроме него. При этом разработчику требуется несколько реализаций. Запечатываем (только) интерфейс (класс) и получаем гарантию, что "никто кроме нас".

А подумать? Ограничивается не доступ собственного (контролируемого) кода, а доступ "посторонних" к возможностям собственного кода.

P.S.
"Я ему - покажи. А он мне - в нашем клубе джентельменам верят на слово. И тут мне карта как попрёт"