The replica is supposed to recover, either if the replica or the master restarts.
The replica has a file in its data directory called relay-log.info
that records the last event the replica processed. Most of the time, this works well, and a replica can resume where it left off.
However, a number of things can go wrong:
The relay-log.info can become corrupted if the replica crashes. For this reason, in MySQL 5.6, they now offer the option to store the same information in a crash-safe InnoDB table instead of in a file.
The replica can be offline for a long time. If the master purges the binary log file that the replica was reading from when it stopped, the replica can't continue. The replica needs to read a contiguous series of events, or else it can't assure full data replication.
The master might corrupt its binary log files if the master crashes. You can reduce this risk by enabling the
sync-binlog
configuration variable on the master, with the understanding that it decreases performance on the master.
As for "why is it implemented [in] such [a] way," why don't you try implementing a replication system that can recover from crashes, and see how easy it is? :-)