For query, any table can be read in parallel without any special regard needed for how it is structured. RAC can be a different proposition because sometimes we'll partition to increase the node affinity (ie, less data going between nodes).

For update, that depends on concurrency. Parallel DML (ie data changing) locks the segment concerned, so whilst you can have "n" worker threads smashing at table, they all belong to a single driving parallel DML operation.

If you wanted to have multiple independent sessions, each performing parallel DML on the same table, then you'd need to

- partition the table
- typically customise the SQL so that a given session (and all of its parallel workers) targets a single partition.

Sequences are of little worry as long as they are cached well, or set to scaleable. ( https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CREATE-SEQUENCE.html )

Indexes hurt parallel *update* performance in the same way they hurt serial update performance. It is common for people to set their indexes to unused for large scale parallel update. For query, index usage is decided by the optimizer in the normal way - just typically the optimizer will often steer clear of them because you're often scanning large volumes of data.