Let's say you're setting an appointment. The user puts in nonsense, so you helpfully schedule an appointment for a nonsense date (thank you so much, we'll get right to that in -124 years). Instead of... catching a parsing error and asking the user to try again or something? It's wild that a nonsense date would be considered for any purpose at all in a user-centric system.
You still need to do some validation of the input because it's difficult to impossible (in many cases) to be absolutely sure the input you receive only comes from your validated form. Even code running entirely within the browser can receive broken/malicious input from an extension, user script, or even the host OS.
It can be a bit belt and suspenders doing validation of specific forms but shit happens. It's much better to catch stuff before it's persisted on the back end or on disk.
That's why I wrote, "validated"
And there can also be man in the middle attacks or whatever, the efforts you do for validation depends still on your task at hand. How critical an error would be.
But even for the most trivial tasks I would never think of passing some user strings to Date and expect to get a valid value.
Then again, I don’t think you pass user input directly into a date constructor in any language, in practice.
You decide on the format that makes sense for the user, you validate the input against that format, and then you map it into a native date.
If the date constructor supports the format you want, it’s only coincidence that makes that final mapping step simpler.
So, the native date constructor having weird behavior on invalid strings doesn’t really change real world code.
If you really ask me, I don't build forms that accept strings as dates from users. There is a date picker element, that can be restricted and validated.