Весь срач не читал, так что отвечу только ОП.

С первого взгляда да, как и написал ОП, вынесение потрохов класса в public дает больше свободы клиентам и меньше головной боли на тему "как заставить эту либу работать так, как нужно нам".

НО:
- самая главная проблема - обратная совместимость. Код, который может использоваться клиентом, уже нельзя поменять без риска сломать компиляцию у зависимых проектов или, еще хуже, внести в них баги. Именно поэтому API так тщательно проектируется, а вся реализация засовывается в private/default область видимости. Злобных буратино с рефлекшном можно игнорировать - сами виноваты.
- вторая проблема - понимабельность. Как правило, именно области видимости формируют у библиотеки API, т.е. что же надо у нее вызывать. Если сделать все public, потенциальный юзер библиотеки не сможет без вдумчивого изучения документации понять, как же ее дергать и какие классы надо использовать.
- третья проблема - декомпозиция. Главное, о чем должен помнить программист - это об ограниченности своего мозга, неспособного одновременно обрабатывать много понятий. Именно поэтому придумана инкапсуляция и блочная структура программ. Чтобы, обдумывая проблему, не нужно было загружать себе в голову детали реализации отдельных модулей.

Что же делать?
Проектирование API - это сложная задача, требующая большого опыта. В качестве библиотеки, где реализация тщательно скрыта от клиента, могу рекомендовать Guava. Образец расширяемой библиотеки для меня - старые модули spring framework, spring-beans например. Изучай, как пишут умные люди и будет тебе счастье.