Я прежде всего имел в виду пригодность для полуавтоматического рефакторинга средствами IDE, что в разы увеличивает объём кода, которым можно управлять в одиночку.

А что вы подозревали, что я имею в виду?

Для domain objects — да: «проксируемые structs» и сервис-объекты. Но, кроме «доменщины», описывающей реальный мир, существуют библиотеки подпрограмм: в них ОО-парадигма служит способом более компактной, удобной и читабельной организации кода. Об этом я написал только последний абзац;-)

Если метод можно прицепить к объекту в runtime-е, а не на этапе проектирования, то это уже не tight coupling. Правда, в нагрузку это ещё и не рефакторится.

Конкретного. Достаточно знания некоего над-типа или интерфейса, чтоб код можно было рефакторить.

Язык может заставлять явно преобразовывать типы. Может делать это сам неявно.

Важно знать типы на этапе компиляции, это делает язык пригодным для «дешёвого» и интенсивного рефакторинга.

Средствами контейнера наинженерить класс-наследник-обёртку, который будет транслировать вызовы на сам объект и возвращать полкченный результат и, кроме, делать что-то до/после(/вместо) получения результата от самого проксируемого объекта (в частности, логгирование или управление транзакциями).

С вызовами функций такая фишка проходит, с обращением к полям — нет.

IRL новорождённых идентифицируют по матери — сразу после рождения прикрепляют соотв. бирку на руку, по крайней мере в 2000 так было.

Свидетель и анонимный донор — это не люди, а роли, делать их потомками класса Person сегодня рассматривается как bad design. Надо не наследовать, а агрегировать.

Для новорождённых тоже можно сделать отдельный класс, не наследуемый от Person.

Вроде ещё в 1987 решили, что при наследовании ничто не должно скрываться и удаляться… Liskov substitution principle — не оно?

Есть, но только иммутабельные;-)

Есть такое понятие — «проксирование». Поля не проксируются, в отличие от методов.