Pause frames were intended to slow the rate of flow to better process at a bottleneck (e.g. packet processing limits or congestion) not as a method to treat Ethernet as a protocol which should have reliable delivery. That's a much more expanded set of standards that came much later. Even Wi-Fi has a (quickly reached) point at which it gives up and lets the data drop because it's better than trying to hold onto it forever just because you can!
I agree the "most dumb" award goes to consumer switches not being 802.3D compliant but even if every switch supported 802.3D fully and avoided the problem it's still silly for the adapters to send pause frames for the reason they did, double so for that long. A single pause frame on a gigabit interface will cover ~33.5 ms. After sending e.g. 100 you're just creating more problems with the received data than you're solving (the switch buffer is full and dropping things anyways, the higher level protocols have already tried to resend, the data from best effort protocols is already stale).
While the topic has come up I'll also throw in every network guy has hated pause frames anyways and most disable the functionality in their networks. The main issues with the original pause frame is it blocks the whole port and doesn't enable a way to selectively signal anything about that to the things trying to send data only the directly adjacent port. There are more modern replacements which enable that kind of stuff for certain DC use cases (usually around storage) but even then flow control at the datalink layer is generally disliked still just not universally.
