Excluding the standard MySQL databases from replication
There's no need to avoid replicating performance_schema or information_schema -- they are not real databases with real tables, they are generated by server internals to interact via SQL, but you'll notice from their table definitions that they aren't normal.  They can't be altered, modified, dropped, created, updated, inserted into, or deleted from... and they don't cause replication events. The performance_schema does not have to be configured the same on master and slave.

The mysql database, you need to allow to replicate, because the users on the master need to be valid users on the slave -- otherwise, you will encounter potential problems with definitions and execution of views, triggers, stored procedures, stored functions, and events, all of which have "definer" attributes that need the defining users to exist on the slave in many cases.

However, you are free to create additional users on the slave as long as you don't, later, generate events on the master that would conflict with those users.

A slave needs to be run in global read_only mode, which prevents users with write permissions granted to them from actually modifying data on the slave, unless they have the SUPER privilege, which bypasses this restriction (which is also why I, as a DBA, have two accounts... I connect to slaves with my account that lacks SUPER unless I have a specific reason to do otherwise).

There is no "tuning" that I can think of that's stored in the system tables in the mysql schema.

All of these things in mind, I'd suggest that the best/easiest/safest approach is to let replication do it's thing and cross any problematic bridges when you come to them... which is typically far less likely when you replicate everything than if you try to be selective.