I think it's funny that removing what looks like actual key material doesn't break a key, but having the wrong kind of newline, or trailing newline in a .pem file can cause certain programs (webservers etc) to not be able to load a cert or key.
https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...
> In text mode, carriage return-line feed (CRLF) combinations are translated into single line feed (LF) characters on input, and LF characters are translated to CRLF combinations on output.
Inserting or removing a control character in a binary file would break stuff too. Maybe even more so.
You may think of the ability to add CRCs (or at least checksums/parity bits) in a binary file? That's extra work, and can be provided by other mechanisms, like par files or at the filesystem level.
The advantage of text formats is that binary decoders for text are ubiquitous. That said, it's usually simple to filter input data through a decoder like gzip.
If a format is human-readable and text based it's both far more likely that a) the spec isn't actually complete (because there's an implicit "sensible" option), and b) people don't read the spec anyway and guess the "sensible" option.
There are countless examples of bugs and security flaws in HTTP that wouldn't have been a problem with e.g. Protobuf.
Rather, what's happening here is that the interpretation of the parsed format is malleable in an arguably incorrect way. There aren't any great solutions that I'm aware of to that, since the "fix" is to validate the correctness of fields that ultimately don't matter to the operation at hand.