I strongly disagree on slave-skip-errors=all.
I always prefer the slave to actually stop replicating upon error. There are good reasons for it to stop replicating. Simply ignoring the errors is, well, error-prone. This is one setting I never use.

Good points for all the rest!

The “expert” will also need
replicate-wild-ignore-table=test.%
# to ignore all the tables from test database

In one case I was handling recently, turning off the binary log, the query cache and adding innodb_support_xa = 0 and innodb_locks_unsafe_for_binlog = 1 increased a lagged slave’s throughput from one to two binary logs per hour to two to four per hour.

Sometimes a mixture of high reliability and high speed slave configurations might be the best solution.

On the slave it’s best to stick to the table-based replication rules if you can. Also all of one type, say a mixture of do and wild do. It’s easier to understand and not get caught out that way. You also get the benefit of not relying solely on the USEd database to determine whether a table can be updated or not, potentially missing updates if the update was carried out from a different database than the table itself.

On the master, do remember that the primary purpose of the binary log is disaster recovery. If you don’t write things to the binary log you’re not going to be able to get them back from it when you’re replaying the binary log after hitting say a serious disk damage based corruption problem. The slaves might save you but it’s worth considering writing more to the binary log.

Oh dear! Yes, indeed! Thank you.

What about read_only on the slave(s)? This should help to ensure that slaves don’t receive accidental writes (assuming application user grants don’t include SUPER).