Ваші інтерфейси мають бути незмінними. Ну, за рідкісними винятками. Збірки, в яких перебувають інтерфейси, можуть мати багатьох споживачів і зміна їх потягне за собою багато інших змін. Натомість можуть з'являтись нові конкретні втілення цих інтерфейсів і зникати старі. Рідко виникає потреба змінити вже наявне втілення, хіба виправити баг чи віддзеркалити зміни зовнішнього, незалежного від вас, API, та й то, можна перевірити версію цього API і вибрати відповідний конктретний клас.

Свої конкретні класи ви реєструєте в DI-контейнері і споживачі знають лише про інтерфейси, які залишаються незмінними.

Так, пам'ятаю, як теж читав дядька Роберта і маю погодитись, приклади у нього дещо перевантажені. Для мене цей принцип про те, що якщо ви хочете додати нову або змінити вже наявну функціональність деякої сутності (класу, інтерфейсу тощо), створіть нову сутність, яка ці зміни втілить, замість внесення змін у вже наявну сутність. Тобто, це про зменшення ризиків, при впровадженні нового коду. І оскільки ви не змінюєте наявний код, ви можете бути впевнені, що він не буде зламаний.

Тобто все вірно

Закриті для змін - тобто наявний код слід змінювати лише для виправлення помилок.
Відкритими для розширення - тобто нові сутності можуть додавати та/чи повторно використовувати наявний функціонал.

Узагальнюючи, цей принцип, це лише порада про те, як можна додавати новий код не ламаючи старий так, щоб ваші користувачі не відчували болю у 5-й точці. Це і є основна ідея цього принципу.

А, ось це більше виглядає як: "опишіть у двох словах, що таке OCP". З однієї сторони це так, але в реальності ви ніколи не можете знати, що може статися. І іноді вам все ж доведеться змінювати ваші сутності.