Здравствуйте, ekamaloff, Вы писали:

E>С Java плохо знаком, но вроде у метода clone есть и еще одна особенность — он кидает исключение CloneNotSupportedException, если поддержка клонирования актуальным классом объекта не поддерживается. Зачем спрашивается такая двойная защита — через уровень доступа и исключения?

если уйти от джава и сказать то же самое в общем виде, получим:
Допустим, все разработчики, пользующиеся какой-либо библиотекой/компонентом, знают, что у одного из классов есть метод с модификатором protected, заявляющий какой-либо контракт и предлагающий дефолтную реализацию. Если мы видим в чужом коде подкласс упоминавшегося выше класса, у которого переопределен этот метод с расширением модификатора доступа, то понимаем, что разработчик переопределил свой метод таким образом, чтобы он удовлетворял контракту. С другой стороны всегда можно и нужно(imho) объявить интерфейс и прописать там весь контракт. Но если дизайн библиотеки/компонента таков, что присутствует однокоренная иерархия с неабстрактным классом в корне, то кажется разумным применить обсуждаемый подход.

По поводу джавы -- мне тоже непонятно, зачем нужна дополнительная проверка. Но пойнт с расширением видимости состоит в том, что если метод clone() не public, я сразу предполагаю, что класс не реализует копирование, отличное от дефолтного(!deep copy).