Date fields were decimal numbers since a certain date. In many environments. Nowadays, they are hopefully just abstract data types representing a Date, i.e. an absolute point in time. The idea of representing a date as milliseconds elapsed since 1-1-1970 in a 32-bit number proved to be a bit problematic, after all 
If a field (as in the first post in this thread) is of type Date, you’re kind of right – format shouldn’t matter, as it’s only representational.
OTOH, how does one get the date into the field? (Again: that was the problem of the first post here). You can do that programmatically, aka in a script, by passing a Date object. Or hopefully manually by entering a string – which has to be in some format. AFAICT, on macOS the acceptable format depends on the global preferences for date types. Which looks practical on the surface and rises apparently some problems in practice. If they’d offer a standardized date format (like ISO’s), everybody would know where they stand.
But the post I was responding to (Date formats broken in Sonoma? - #6 by spoiltvictorianchild) was not talking about a date field with type Date. Its author wants to add a date to a filename. Which is a string. So the date becomes a string, and then format matters.
The alternative (again: sortable!) would be ISO’s yyyy-mm-dd. Standardized, systematic, and language-independent (your “Jun” is a Turk’s “Haz”, a Serb’s “Јун”, a Chinese’s “六 月” (literally 6th month), and an Albanian’s “Qërshor”). Of course, language independence doesn’t matter if you’re not dealing with people from non-english environments. Sortability might matter, though: In your system, 01-Apr-23 comes before 01-Jan-23.