Формально дата По лишняя, кроме того случая, когда период действия данных завершается окончательно. На практике интервал [С, По] позволяет упростить выборки нужных строк из таблиц, например писать sysdate between С and ПО, вместо конструкций с подзапросами min/max.
Кроме того индекстирование по ключу (ID, С, ПО), позволяет находить ROWID нужной строки только путём сканирования индекса по диапазону не обращаясь к сегменту таблицы. В результате существенно сокращается количество логических чтений и увеличивается производительность запросов.

Делить отношение на таблицы по принципу изменяемые/неизменяемые атрибуты, тем более выделять отдельные колонки нет смысла. На соединениях в запросах потеряешь больше, а определить какой атрибут изменился очень просто сравнив поля в соседних записях.

Самая главная проблема это ввод первичных данных.
Практика показывает, что возьня с датами, а тем более с интервалами сильно усложняет работу оператора и логику приложения (нужно отслеживать пересечения интервалов, правильно делать блокировки, исправление ошибок становится нетривиальной задачей и т.д.). Решением может быть создание Front-end подсистемы для заведения первичных данных, в виде максимально приближенном к формату источника. Затем после заведения и проверки данных нужно отразить их в исторические записи, пригодные для удобного использования во многих подсистемах. Кроме того нужно предусмотреть операцию исправления первичных данных, если в них обнаружились ошибки, и повторного применения в историческую подсистему.
Часто новая версия документа отличается от предыдущей только датой вступления в силу и изменениями нескольких строк или полей. В этом случае полезно иметь функцию создания новой версии документа по образцу существующей версии. В связи с этим возникает интересная задача трассировки версий, например для поиска и исправления растиражированных ошибок (вспомним Copy/Paste ).

NFЕсли ДатаОкончания не указана, значит ее или нет, или это ДатаНачала следующего значения минус 1 день (час/минута/секунда зависит от задач).

Будь проще. Прикинь как будут выглядеть SQL запросы со всеми этими заморочками! Заколебёшься предикаты выписывать.

NFПотому что есть понятие нормализации

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

NFоднако красота схемы заставит нас впасть в нирвану.

Боюсь, от такой красоты в нирвану впадёт СУБД и будет в ней пребывать неопределённо долго.

NFЕсли периодических атрибутов слишком много, то возможно и правда удобнее хранить их в одной таблице, чтобы не загромождать схему, выставив предварительно в отношении признак ТипАтрибута (правда тогда надо будет еще сделать справочник ТипыАтрибутов, опять же чтобы избыточность не плодить).

Это EAV со всеми вытекающими последствиями.