Most people on this site probably live in the world where everything is done in English. That's the norm for the vast majority of businesses and people in the US.
You can choose to never work on projects where you have to deal with files like that.
But there may come a day where you have to choose between not paying your rent or writing a tool that converts old textfiles to UTF-8. At that point, it's nice to have references on the internet on how other people have actually dealt with it and what works. "Abort with an error" is not very useful advice then.
What are the common pitfalls that the library must deal with?
How do you know how to evaluate them if all you know is "not UTF-8? Abort with error" ?
Do you have any experience at all with different charsets under the hood by the way?
There are examples of where people used encryption libraries in the wrong way and undermined the strength of the encryption (for example, CVE-2024-31497 in PuTTY).
A very big part of software development is dealing with leaky abstractions. We don't work with perfect black boxes. We need to understand enough of how things works in the lower layers to avoid problems. Note here that I wrote "enough", not "everything", or "write everything yourself".
I would not want a person writing software to handle charset conversion if he refuses to learn how the various encodings work, which charset will decode as another charset or not, etc.
"older approach, PuTTY developers said, was devised at a time when Microsoft Windows lacked native support for a cryptographic random number generator."
So "enough of how things work" could just be "pick a modern encryption library" that doesn't come from the dark ages when t there were no random numbers
Same with encodings, it requires a much lower level understanding to pick a library, you can rely on the expertise of others