I doubt there's anything else involved than the relevant function trying to be helpful. In interactive use, it might be beneficial for the utility to accept an abbreviation so the user can be lazy.

This is a question of Postel's law (i.e. "be lenient in what you accept, but strict in what you output"), and the leniency there is not always a good rule to follow, since behaviour that people get used to can influence future possibilities for change. In this case, a future option might make an earlier valid abbreviation invalid, but as long as script authors take the time to spell options out in full, there's not much risk of issues. Interactive users can use abbreviations more easily, since if they get an error after an upgrade, they can be assumed to be easily able to fix their command.

I doubt there's anything else involved than the relevant function trying to be helpful. In interactive use, it might be beneficial for the utility to accept an abbreviation so the user can be lazy.

This is a question of Postel's law (i.e. "be lenient in what you accept, but strict in what you output"), and the leniency there is not always a good rule to follow, since behaviour that people get used to can influence future possibilities for change. In this case, a future option might make an earlier valid abbreviation invalid, but as long as script authors take the time to spell options out in full, there's not much risk of issues. Interactive users can use abbreviations more easily, since if they get an error after an upgrade, they can be assumed to be easily able to fix their command.

Scripts using an abbreviation could indeed be a problem, and avoiding the issues there would be the argument for not being lenient on input. But apparently in this case, the library authors have made the choice that accepting abbreviations is ok.