MM-DD is not terrible.
It was a useful format for a very long time, and in contexts even today, it is still appropriate. Say I have a bunch of dates associated with things I want to organize, maybe physical things. First of all, in my organization, the year is either inconsequential or it's just implied - "the current year". Ok. What's next? The month. So the month and the day are most significant. And say I want to file things away in a cabinet for the implied or current year - we go by month first, then day, not day then month - that would be silly. And colloquially we say "month/day", and again, the year is implied. So then we write the way we speak things, and that yields MM-DD. When we do add the year, it just comes at the end. That's not terrible, it's useful for what we need it for.
In American, the format emerged organically, it was useful (still is), and it just stuck.
If you're a software engineer and you need YYYY-MM-DD dates because they're easier to work with and they collate more appropriately, that's great, that's your use-case. Engineers, however, are infamous for not considering others' use-cases, least of all the use-case of the users they're actually building their program for! Perhaps that's why so much modern software is just so user-hostile.
Perhaps the engineer should consider that his goals and use-cases are not necessarily the same as other people's. And perhaps he should stop trying to impose his own goals and use-cases onto others. And before he criticize others' specs, reqs, and use-cases, perhaps he should make an attempt to understand them to begin with.