Why does mysqldump stop the slave SQL thread for the entire backup?
--single-transaction obviously only preserves a transaction for the transactional tables.

The STOP SLAVE is needed to preserve the consistency of the dump of the MyISAM tables. If there was logic in mysqldump to dump the MyISAM tables first, it could START SLAVE at that point (in a different connection as START SLAVE probably an implicit commit`), and continue dumping the InnodDB tables.

The STOP SLAVE is also required as DLL isn't transactional. What could happen is while tables are being dumped, a CREATE TABLE / DROP TABLE could happen in the replication stream, and as those aren't transactional, the dump would then be inconsistent.

Why --master-data assumes it isn't a slave and doesn't need the same level of protection is anyone's guess. Why --master-data issues a FLUSH TABLES WITH READ LOCK around dumping position information and dump slave doesn't? Why the UNLOCK TABLES happens before the data dump starts? Also a mystery.