При написанні досить великого шматка коду (неважливо, класу, функції або чого-небудь ще) важливим прийомом є декомпозиція. Ви ділите функціональність на логічні частини, і в головній функції складаєте з них, як з цеглинок, загальну логіку.

При цьому самі цеглинки можуть бути не пристосовані для доступу зовні. Наприклад, відкритий метод може перевіряти вхідні параметри, а допоміжним методам-цеглинам це вже не потрібно, оскільки вони викликаються лише зсередини. Якби ці методи були відкритими, в них потрібно було б реалізовувати перевірку параметрів, і при їх імплементації не можна було б розраховувати на те, що вони будуть викликані в контрольований вами момент.

Крім того, внутрішні методи мають право псувати стан класу, якщо ви знаєте, що код який їх викликає потім цю проблему виправить. Якщо зробити ці методи відкритими, користувачі цього класу зможуть зіпсувати внутрішній стан класу без виправлення.

Потім, внутрішні методи можуть не мати нічого спільного з тим, що повинен надавати клас, з його зовнішнім інтерфейсом. Наприклад, якщо клас представляє машину, то відкритий метод в ньому, що переводить дюйми в сантиметри, виглядав би безглуздо. А ось всередині такий переклад цілком може знадобитися.

Ну і в кінці-кінців, публічний метод - це обіцянка для користувачів. Кожна зміна (видалення, зміна сигнатури, а іноді і додавання) відкритого методу - breaking change для клієнтів, вони повинні переглянути код, який використовує ваш клас. Таким чином, ви не повинні просто так, без особливої на то потреби міняти відкриті методи класу. А ось зміни в закритих методах зазвичай відбуваються при рефакторінгу в масовому порядку: методи спрощуються, об'єднуються, розкладаються на декілька, переносяться вгору-вниз по ієрархії, змінюється їх семантика, і все це ніяк не відбивається на користувачах вашого класу.