2 softwarer +0.75 с уточнениями

П1 - Указанный вами пункт 1 не является главным недостатком предложенной схемы.
Т.к. в схеме просто нет сущностей «проверяющий» и «проверяемый» и нет ясного понимания причины их отсутствия, то нет и оснований для выставления этого момента на первое место. Такое его творческое видение предмета, что «проверяемые» с «проверяющими» вовсе не сущности, а просто атрибуты. Составит это проблему для его задачи или нет – предмет правдоподобного, но домысливания.
К недостаткам предложенной схемы это относимо с натяжкой.
Тем более, что превращение их в сущности не составляет формальной проблемы в предложенной схеме.

П2 про излишество N-N – по существу – почти наверно - да.
N-N может оказаться практически неприемлемым при переименовании атрибутов. Но может и не оказаться.

П3. В предложенной схеме это главный недостаток.
Может быть компенсирован
- либо организацией интерфейса пользователя ( не гарантирует от ошибок программиста и администратора БД)
- либо организацией нетривиальных условий проверки целостности c использованием check constraint (если выбранная субд сможет их поддержать) или триггеров ( с тем же условием.).

Либо изменением характера связей между сущностями и перепроектированием сущности [Результаты_проверки].

Так, если изменить связи между [Объекты_проверок] и [Проверки]
И между [Объекты_проверок] и [Справочник_атрибутов_по_объектам]
С неидентифицирующих на идентифицирующие, то использованные в схеме сущности
более-менее естественным образом можно представить так;


[Объекты_Проверок](АйДи, прочие_атрибуты)
PK(АйДи)

[Справочник_Атрибутов](PK,АйДи, прочие_атрибуты)
PK(PK,АйДи)
FK(АйДи) REFERENCES [Объекты_Проверок](АйДи)

[Проверки](PK,АйДи, прочие_атрибуты)
PK(PK,АйДи)
FK(АйДи) REFERENCES [Объекты_Проверок] (АйДи)


[Результаты_проверок](PK,PK_П,АйДи,PK_А, прочие_атрибуты)
PK(PK,PK_П,АйДи)
FK(PK_П,АйДи) REFERENCES [Проверки](PK,АйДи)
FK(PK_А,АйДи) REFERENCES [Справочник_Атрибутов](PK,АйДи)

Использованный переход с идентифицирующим зависимостям позволит явно указать дерево зависимости сущностей - [Справочник_Атрибутов] оказывается явным образом ведомым для сущности [Объекты_Проверок], а [Результаты_проверок] явным образом ведомая для сущности [Проверки]. Дополнительно, такой вариант оформления сущности
[Результаты_проверки] автоматически не даст возможности допустить ошибку связывания строки проверки с атрибутом чужого проверяемого объекта без использования как heck constraint, так и триггеров.
П3 – ключевой в рамках предложенной схемы (если принять характер связей как адекватный предметной области – независимо от справедливости такого принятия, то проблема именно в сущности [Результаты_проверки]).


П4 – вопрос вкуса/стиля

П5 – домысливание задачи за пределы предложенной для выявления недостатков схемы.