Doesn't really work like that. There are plenty of scenarios where IN is better than NOT IN, and equally when NOT IN is better than IN.

A good discussion here

https://asktom.oracle.com/ords/asktom.search?tag=in-vs-exists-and-not-in-vs-not-exists

But I would always look at writing code which maps to the business requirement.

Let's say a table has three types of employee: FULL TIME, PART TIME, CONTRACT, CASUAL

If someone said to me: "Find all the employees that are not contractors or casuals", I would write:

WHERE EMP_TYPE not in ('CONTRACT','CASUAL')

because it maps to the requirement. If one day we add some more types, my query still works.

Similarly, if someone said "Find all the full and part time employees", I would write:

WHERE EMP_TYPE in ('FULL TIME','PART TIME')

for the same reasons.

If in either case, the performance did not meet my needs, I would like at the *why* before changing my query.