APEX_PUBLIC_USER is simply your means to get a connected session onto the database.

However, it will do almost all of its work via calls to the routines in the APEX owning schema, eg APEX_050100. Now *that* user has a whole different set of privs :-)

SQL> select * from dba_sys_privs
  2  where grantee = 'APEX_050100';

GRANTEE     PRIVILEGE                                ADM COM INH
----------- ---------------------------------------- --- --- ---
APEX_050100 INHERIT ANY PRIVILEGES                   NO  NO  NO
APEX_050100 CREATE JOB                               YES NO  NO
APEX_050100 CREATE MATERIALIZED VIEW                 YES NO  NO
APEX_050100 CREATE TABLE                             YES NO  NO
APEX_050100 UNLIMITED TABLESPACE                     NO  NO  NO
APEX_050100 DROP TABLESPACE                          NO  NO  NO
APEX_050100 ALTER SESSION                            NO  NO  NO
APEX_050100 EXEMPT REDACTION POLICY                  NO  NO  NO
APEX_050100 CREATE OPERATOR                          YES NO  NO
APEX_050100 CREATE VIEW                              YES NO  NO
APEX_050100 CREATE TYPE                              YES NO  NO
APEX_050100 CREATE ROLE                              NO  NO  NO
APEX_050100 CREATE SYNONYM                           YES NO  NO
APEX_050100 ALTER USER                               NO  NO  NO
APEX_050100 CREATE CLUSTER                           YES NO  NO
APEX_050100 CREATE DIMENSION                         YES NO  NO
APEX_050100 CREATE TABLESPACE                        NO  NO  NO
APEX_050100 CREATE TRIGGER                           YES NO  NO
APEX_050100 ALTER DATABASE                           NO  NO  NO
APEX_050100 CREATE PUBLIC SYNONYM                    NO  NO  NO
APEX_050100 CREATE USER                              NO  NO  NO
APEX_050100 CREATE SESSION                           YES NO  NO
APEX_050100 CREATE INDEXTYPE                         YES NO  NO
APEX_050100 CREATE PROCEDURE                         YES NO  NO
APEX_050100 CREATE SEQUENCE                          YES NO  NO
APEX_050100 DROP PUBLIC SYNONYM                      NO  NO  NO
APEX_050100 DROP USER                                NO  NO  NO

If we throw a trace on a typical APEX session, you can see how this pans out. In my AskTOM session, I see some calls like this:

PARSING IN CURSOR #2365700804328 len=460 dep=1 uid=111 oct=3 lid=111 tim=94078296179 hv=2948261869 ad='7ffd94698958' sqlid='f85v6nurvptzd'
SELECT /*+result_cache*/ NAME, VALUE FROM WWV_FLOW_PLATFORM_PREFS ...

and when I look in DBA_USERS, I'll see that user 111 (uid=111) is APEX_050100. Later in the trace file I'll see things like:

PARSING IN CURSOR #2365700447264 len=79 dep=1 uid=131 oct=47 lid=131 tim=94078425268 hv=30811219 ad='7ffd73aec580' sqlid='d8661xh0xc92m'
begin wwv_flow.g_boolean := not page_brch.question_valid(:P11_QUESTION_ID);
 end;

and when I look in DBA_USERS, I'll see that user 131 is ASKTOM (the schema that is registered with this workspace)

By the way, this is a good model for your *own* applications. Have an account that connects to the database, but that account can only access API's published by a more powerfull account that owns the source code, or owns the tables and the source code. That way, no-one *ever* has to login to the database as the schema that owns your tables, and hence reduces risk of error and/or data breaches.