And that kind of thing might still work today for devices that respond to ICMP pings.Not so much any more aside from your example of saturating a really tiny link. Most routers are either based on Linux or BSD and ICMP is rate limited using a few knobs and masks icmp_ratelimit, icmp_msgs_per_sec, icmp_msgs_burst based on icmp_ratemask. Enterprise routers have even more rate limiting that factor in back plane CPU load and other vendor specific controls. Enterprise routers will appear to stop responding or appear to have packet loss but they are just silently dropping ICMP when the rate is over their set thresholds as defined by the vendor defaults or by the network administrator.
Give it a shot some time on Linux or BSD. Install iftop to watch network usage and htop or btop to watch CPU usage and flood yourself with one of the ping tools fping, hping3, nping, blitzping, etc... Ideally blizping but you may have to compile it. Just for fun start loosening the sysctl restrictions on ICMP rate limits and find the spot where your CPU load is undesirable to the point where applications lag.
On the topic of security it is a good idea to block ICMP redirects unless one knows they need it. Or conversely a more restricted approach would be to allow Echo Request, Echo Reply and maybe Destination Unreachable outbound for pmtu discovery. Address Mask Request/Reply can be considered information disclosure to some organizations. It is also a good practice to disable responding to ICMP broadcasts in the OS via sysctl unless you know you need it.