PostgreSQL parallel scan with "greater" or "less" than
Your &gt; query returns hugely more rows than =.  Each of the rows being returned from a parallel worker needs to get passed up from the parallel worker to the leader, and doing this is not free.  (This is the cost accounted for by parallel_tuple_cost).  A row filtered out by the parallel worker, on the other hand, does not suffer this expense as it is not passed up.  If most rows will be filtered out, it makes sense to do the filtering in parallel.  If few rows will be filtered out, it might not make sense to do the filtering in parallel but then do the extra work of shuffling the data around between processes.
What you have not shown us is whether doing the &gt; query in parallel is actually faster than doing it in a single process.  Maybe you need to tune parallel_tuple_cost down some.  The default settings is quite conservative.