Explain Plan is your helper in such cases of doubt.
It shows in the Predicate Information block the exact predicate that Oracle uses.
Here the results for your two queries limited to the predicate information
For <>
EXPLAIN PLAN  SET STATEMENT_ID = 'neq' into   plan_table  FOR
select * from table_name where comp_date <> sysdate -10;
SELECT * FROM table(DBMS_XPLAN.DISPLAY('plan_table', 'neq','ALL'));
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter("COMP_DATE"<>SYSDATE@!-10)
For !=
EXPLAIN PLAN  SET STATEMENT_ID = 'neq' into   plan_table  FOR
select * from table_name where comp_date != sysdate -10;
     
SELECT * FROM table(DBMS_XPLAN.DISPLAY('plan_table', 'neq','ALL'));
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter("COMP_DATE"<>SYSDATE@!-10)
What you can clearly see it that Oracle uses only the <> operator internally.
So no difference is expected.
Despite this exercise, you may also make a thought experiment only.
You know that sysdate is of a DATE data type , i.e. without second precision. Your timestamps have second precision.
So a not equal comparison will  always be true. Compare a TIMESTAMP with a DATE conveverst the DATE in a TIMESTAMP (without second precision) as you can see in the example
EXPLAIN PLAN  SET STATEMENT_ID = 'neq' into   plan_table  FOR
select * from table_name where comp_date != to_date('2022-01-25 16:59:59','yyyy-mm-dd hh24:mi:ss') - 10;
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - filter("COMP_DATE"<>TIMESTAMP' 2022-01-15 16:59:59')
So recheck your setup and try to repaet the result. Maybe the cause it as trivial as that the table was not filled at the time of the check, comp_date was NULL etc.