Mainly due to two reasons:
- Allow enough time for all bridges to hear the change in the topology.
- Avoid duplicate frames.
From Understanding and Tuning Spanning Tree Protocol Timers see below:
The movement of a port into the listening state indicates that there is a change in the active STP topology and that a port will go from blocking to forwarding. So the listening and learning periods during which the forward delay runs must cover this consecutive period:
Time from when the first bridge port enters the listening state (and stays there through the subsequent reconfiguration) to when the last bridge in the bridged LAN hears of the change in the active topology
In addition, you need to count the same delay that you use to calculate max age (message age overestimate and BPDU propagation delay).
Time for the last bridge to stop forwarding frames that are received on the previous topology (maximum transmission halt delay), until the last frame that is forwarded on the previous topology disappears (maximum frame lifetime)
This amount of time is necessary in order to be sure that you do not get duplicated frames.
Therefore, twice the time of the forward delay (listening time + learning time) contains all these parameters. The formula is:
2 x forward delay
= end-to-end_BPDU_propagation_delay + Message_age_overestimate +
Maximum_frame_lifetime + Maximum_transmission_halt_delay
= 14 + 6 + 7.5 + 1 = 28.5
= 28.5 /2
= 15 (rounded)
Networking protocols and industry requirements have changed since when STP was initially created.
STP is kind of old and has evolved into further flavors like RSTP, PVST, PVST+, MSTP to satisfy the need of faster and more resilient networks.
For example let's compare STP vs RSTP topology change and you will clearly see why STP is so slow. STP had to wait the TCN flag all the way up from the Root Bridge.