If you look at dba_users.oracle_maintained you will see all the schemas in which you should not create objects.

John Watson wrote on Sun, 17 March 2024 12:57

If you look at dba_users.oracle_maintained you will see all the schemas in which you should not create objects.

Is 'should not' somehow enforced or is that a gentleman's agreement?

An arbitrary DBA or developer may create them even under SYS

C:\Users\john>sqlplus system/oracle

SQL*Plus: Release 19.0.0.0.0 - Production on Mon Mar 18 07:03:32 2024
Version 19.17.0.0.0

Copyright (c) 1982, 2022, Oracle.  All rights reserved.

Last Successful login time: Sun Mar 17 2024 13:41:40 +00:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.17.0.0.0

orclz> conn system/oracle
Connected.
orclz> create table sys.cannot(c1 date);
create table sys.cannot(c1 date)
*
ERROR at line 1:
ORA-01031: insufficient privileges


orclz>

And if someone didn't it'd just mess up their server and would be blocked from entering source code on review.

OK but why not prevent from doing such things at the source instead of detecting them during review? It just a waste of resources and time and money for the company.
Why any developer should have access to SYS?

Even if security in dev environment is more relaxed, it does mean it could be anything.
If a developer kills a dev db who will recreate it? What about the lost time for all developers?

OP's issue, in short, is that some high privileges has been granted to user now he has to check they didn't use them.
In his previous topic, it was a script is given to DBA to be deployed but he wants this DBA to understand the script before executing it. But these scripts should have been validated before and the DBAs who deploy them haven't to analyze but just to execute.
Roughly, all OP's questions are about how to verify things are correct despite the fact that we do any old how, instead of thinking to make things so that they cannot be otherwise than correct (but as he said this is just a philosophical point of view).

Oh.
You still think of me as of a dev or DBA who makes decisions to create or not create objects, read/understand/run or not to read/understand/run scripts, etc, even though I never indicated that.
You should not try to follow or investigate me because I come here with isolated, technical questions that have no connections between them unless I indicate that one flows from the other.
Those who may have created such objects are neither myself or my coworkers: they are hypothetical past or present DBAs or devs who make their own decisions, however right or wrong, good or bad, and I only have to account for any possibility. That is as much as I am allowed to say.

The only purpose of this particular question is to find a way to filter out Oracle's OOB tables from queries...  in MS SQL it is straightforward

I cannot by looking at schemas alone tell whether a table comes OOB with the Oracle engine or is created after the installation. Seeing how there are thousands of tables in a vanilla installation of Oracle, it sounds impossible for me to tell which table is vanilla and which is not.