From the documentation (added by me separately):
If you use streaming replication without continuous file-based archiving, you need to set wal_keep_segments in the master file to a value high enough to ensure that the old WAL segments are not processed too early, while in standby mode you may still need to catch them . If the backup is too far behind, it must be reinitialized from the new backup database. If you set up a WAL archive that is accessible from standby, wal_keep_segments is not required, since in standby you can always use the archive to catch up.
So, from my understanding, when you have too many transactions, a slave may have a hard time staying in sync. Especially if the wizard deletes the WAL files before the subordinate really gets what is inside. Without archive_mode on the wizard, WAL files can be deleted, leaving no way to return them.
If you keep WAL archiving in place and add streaming to the hot spare-with-archives work structure, this cannot happen, because the subordinate can always access the archived WAL and will return unsynchronized transactions as soon as the lower activity on the stream allows this is. Without access to the archive, risk can obviously lose the integrity of your slave after some really hard things.