What should be happening: SQL won't use the clustered index, it will use the non-clustered index to perform a sargable search for [person] then use the clustered index [datekey] hidden inside the non-clustered index to evaluate the rest of the criteria and return the result.
What could be happening: The search criteria for [datekey] is non-sargable and ...
"Duct Tape" option: Remove the index on ID_User and replace it with an index on (ID_User,CREATION_DATE).
Best option: Get rid of the Id and find another suitable primary key such as (ID_User,<timestamp>). This is preferable as it would: ensure uniqueness, remove the need for one index, and get rid of a useless column.
You should enable BPE and test it using your existing SSD drive(s) first to see if you get any performance improvement at all from BPE. It's going to depend on your workload and waits and if your current SSDs are locally attached as the BPE drive should be.
SQL Server I/O and CPU Cost is an estimate of seconds from the year 2000.
SQL Server estimates that each I/O will take 3.125 ms (i.e. 1⁄320 s, because of the assumption that the disk can perform 320 I/O operations per second. 1⁄320 = 0.003125). Each I/O is fetching an 8 KB page from the disk.
This is one of the "magic numbers" inside the SQL Server ...
I made tables and queries from your situation. Even though they are not the same as yours, it will be helpful to solve the issue.
create table students
create table student_point
create index idx_student_point_02 on student_point(exam_seq,...