Does increased Data Dictionary size affects performance

It depends entirely on what you are doing with the data.

For basic insert/update/delete transactions that affect just a few rows, then the growth in data size is probably not a big consideration. The database will use in-memory indexes to access the correct page. You get more cache misses when the tables no longer fit into memory. However, the overhead might be slight -- depending on the database, database configurations, and hardware configurations.

If you are doing queries that require full-table scans, then your performance is going to grow linearly or worse with the data size. Indexes can actually make the situation worse, by randomizing page accesses, which then pretty much guarantee cache misses.

An alternative to more memory is improved disk speed -- solid state disk can provide tremendous improvement.

Just having more data is unlikely to affect performance unless the tables are used in queries. Is the data redundant within a table or across tables? Having large tables that never get used is messy, but has minimal impact on performance. It is imaginable that if you have zillions of unnecessary tables, then then compiling queries could start to take more time.

To get a list of partitioned tables that have at least one referencing partitioned child table the [dba][all][user]_part_tables and [dba][all][user]_constrains data dictionary views, depending on the privileges granted, can be queried:

create table tb_part_parent(
  col  number primary key,
  col2 number
)
partition by range (col2) (
  partition part_1 values less than (100),
  partition part_2 values less than (300),
  partition part_3 values less than (500)
)

create table tb_part_child(
  col  number not null,
  col2 number,
  constraint fk_parent_1 foreign key(col) references tb_part_parent(col)
)partition by reference (fk_parent_1)

The query:

select t.table_name
  from user_constraints t
 where t.constraint_name in ( select w.r_constraint_name
                                from user_constraints w
                                join user_part_tables q
                                  on (q.table_name = w.table_name and
                                      q.ref_ptn_constraint_name = w.constraint_name)
                              )

Result:

TABLE_NAME
-----------------
TB_PART_PARENT