I know from the corresponding thread on the mailing list that it is an intentional change for the sake of crash-safety, so it is just a documentation request.

With traditional (binlog-position-based) replication it is quite possible and even reasonable to setup master binlog purging procedure based on the slave IO thread status: as soon as the IO thread is done with a master binary log and switched to the next one, all events are in the relay log, and the master binary log can be purged. It is efficient in the sense that if the slave thread is far behind, a lot of disk space can be spared by not storing the same events both in the master binlog and in the relay log; even more so if the server features the sql_delay (master_delay) functionality introduced in MySQL 5.6, and the slave is configured to keep a time gap with the master.
It also saves the network traffic if the lagging slave gets restarted, because the local relay logs are preserved and the IO thread does not have to re-read all the events again.

So, all in all, I expect there are real-life configurations which rely on this behavior.

Now, with GTID the relay logs are not stored on slave restart any longer, so users must not configure their purge procedure this way, but should use SQL thread position instead. It needs to be explicitly documented, because otherwise users can experience irreversible loss of events.