Recommendations for my.cnf on MySQL Replicant
There are no hard-and-fast rules for such Slaves. Let's look at two scenarios

SCENARIO #1

Some standardize all DB Servers to have the same configuration. The rationale behind this is promote a Slave to a Master should have to fail over to it.

SCENARIO #2

A scaled down Slave being used as a data backup. No reads from that Slave.

COMPARISON OF SLAVES

For a Slave whose sole job was backup and simple data redundancy, using less optimization is fine but can come at a premium. How so ?

If you have Master that has high write volume, this can result in MySQL Replication having lots of Replication Lag (Seconds_Behind_Master > 0 and increasing). This can occur when a Master has 20 INSERTs, UPDATEs, and DELETEs happening in parallel. Those 20 commands are serialized in the Master's binary logs and are serially processed by the SQL thread on the Slave. If you scale down the hardware and MySQL config settings on the Slave too much, that Replication Log can get worse than the aforementioned serialization of updates.

CONCLUSION

The volume of writes on the Master should be inversely proportional to scale down of the Slave:


the higher the volume of writes on the Master


the less the scale down of the Slave
the lower the tolerance for Replication Lag (preferably none)

the lower the volume of writes on the Master


the more the scale down of the Slave
the higher the tolerance for Replication Lag (expected to be infrequent)



CAVEAT

In this context, scale down means


less RAM required 
less need for CPU/cores
lower cache settings


innodb_buffer_pool_size
innodb_log_file_size (default is OK)
innodb_log_buffer_size (default is OK)
key_buffer_size

lower max_connections


UPDATE 2015-02-02 12:53 EST

Based on the question in your comment about writes, you can increase the following on the Slave


innodb_write_io_threads to tweak the CPU for writes
innodb_log_buffer_size to cache writes