Динамические возможности CLOS

Да

Намерено сархитектуреной деталью MOP. образ с всегда наличествующим компиляторм детали делают реализаци некостыльной.

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

Суть в разнице понимании жизненого цикла в C и лиспах. С-шная програма должна когда-нибудь завершить работу вместе с main(...). У Лисп-образа нет внутрених причин завершать свою работу. И если увеличить маштаб времени например до года то потребность в корректировки для соответсвия реалиям внешнего мира будет уже существеной.

Основной фишкой является возможность манипуляции символами в рантайме. Ну и наличие компилятора. Всё остальное - детали.

чисто для интересу: память на символы конечная, чистится в рантайме? Т.е. если сделать веб-сервак, который имеют тыщи людей на постоянной основе, не окажется так что вся память под символы закончилась и давай досвиданья?

Символы можно удалять.

У меня при изменении конфигурации FPGA просто тупо грохался пакет (типа неймспейс), в котором описания ядер и настроечно-мониторный код сидел. Вся MOP'щина спокойно подметалась, ничего не текло и не падало, аптайм месяцами был.

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

Все вместе. Как ни странно, но многие вещи в Common Lisp сильно взаимосвязаны, и это не так очевидно в начале. Что интересно, многие из них прошли проверку временем.

Еще CLOS хорош для кодо-генерации с помощью макросов.

возможность в рантайме изменять методы обобщённых функций, слоты классов, перестраивать иерархию наследования, изменять классы ранее созданных объектов. Я вполне могу представить, как это всё используется в интерактивном режиме в процессе разработки, но что-то юз-кейсы, когда самой программе может это понадобиться, ограничиваются только какими-то несбыточными фантазиями про ИИ.

До SQL структура БД задавалась в момент «компиляции» этой самой БД. А потом зачем-то придумали DDL. Область применения та же.