Those are indeed the "magic" bytes of PNG. It's a very clever choice meant to ensure the transport layer didn't mess with it.
To start, there's a byte with the upper bit set which ensures an "8-bit clean" transport. If it's stripped, it becomes a harmless tab. Then the literal "PNG" text so you can see it in a text editor. Then a CR-LF pair to check for CR-LF to LF translations. Then, a CTRL-Z to stop display on DOS-like systems. And finally, another LF to check for LF to CR-LF translations.
It's a clever "magic" that basically ensures a binary transport layer. Things that mattered back in 1996.
It's clever but I'm not so sure it actually mattered - other formats have done just as well with simpler magic numbers. All it does in the end is that you get something that doesn't identify as a PNG file rather than a PNG file with bad data when a non-binary transport is used - both results are bad and immediately apparent.
Yes and no. It wasn't just about telling you a problem occurred, but failing early and being able to say exactly why. A "something in the chain is running in 7-bit mode" is more helpful than "CRC error in IDAT". Maybe the developers were being a bit too ambitious/hopeful, but an eight byte "magic" over a "simpler" four byte one isn't really worth crying over, even with 1996 download speeds.
