High disk IO with MySQL master-master replication
ALTERs being replicated?  They could be low replication bandwidth but high I/O.
How much RAM?  innodb_buffer_pool_size is quite large.
Do your tables have lots of secondary indexes?
Was there previously a lot of activity that led to updating secondary, non-UNIQUE, indexes?  The Change Buffer is in the buffer_pool and it is flushed asynchronously.  See innodb_change_buffer_max_size, but don't necessarily change it.
Lots of TRIGGERs?
How big are the tables?
In spite of ROW, might a full-table UPDATE have gone through as STATEMENT?
LVM's COW may double (or triple?) the I/O activity.  (But this would only partially explain what you are seeing.)
Are some big SELECTs happening?  (Turn on the slowlog, with a small value for long_query_time.)


No, I don't see any configuration changes to make.

More

Some issues that may be relevant (especially after updates to the Question)


For a single UPDATE of 1K rows,  Row Based Replication is rather verbose.  Each row is a separate record in the replication stream, and it is rather large (compared to the update, itself).  These records will be buffered and written to the Master's disk (binlog) and to the Slave's disk (relay log).  I would assume that they are buffered, etc, so that the amount of writing is the same.  But maybe I am wrong.
The "sql thread" on the Slave reads all of these 1-row updates, presumably one at a time.  Again, one would hope that there is buffering such that this does not add to the I/O.
Both machines need to update any secondary keys via the Change buffer.  However, this is a delayed action.  In fact, it might be delayed so long that it won't show up on the graphs you have presented.
In a Master-Master setup, I do not know when the "loop" is stopped.  That is, server_id 123 replicates to its Slave, server_id 234, which then replicates to all of its Slave, including 123.  Upon discovering 123=123, the replication packets are dropped.  But does that happen before getting back to 123 and being written to the relaylogs there?  I don't know.  You can figure it out by looking at the growth of the relaylogs on the active Master.
What other logs does the Slave have turned on?  Presumably the same as the Master.  General log?  Slow log?  Others?


Scenario details


SET autocommit=0;
DELETE all of 1-2K rows in a particular table. If all at once, and Row-based-replication, then a lot is sent through the replication stream.
INSERT one row back in
INSERT one row back in
... 1-2K rows inserted
COMMIT;  It is not until this point that anything goes across to the Slave.  I suspect this is when the binlog is being written all at once.


Well, I guess this still does not answer your question, but maybe it provides some more insight.

How to replace a table

This is a more efficient way to replace all of a table.  It avoids the table ever being out of service:

CREATE TABLE new LIKE real;
load the new data into the table (LOAD DATA or multi-row INSERT(s) is best)
RENAME TABLE real TO old, new TO real;
DROP TABLE old;