The problem with the all digits string is it can be mistaken for an integer.
100% false. Date literals are strings, or delimited in some other way to distinguish them from int (e.g. Access uses #s (for some unfathomable reason); DB2 uses quotes, like SQL Server).
At any rate, 2019-10-11 would also be an integer: 1998 (2019 minus 21). Try SELECT 2019-10-11 in whatever dbms you want and I figure close to 100% of the time you'll get a result of 1998 and not 2019-10-11.
why do dashes change the nature of the interpretation?
I believe to be consistent with local practice. Otherwise it would be terribly confusing for people to enter SQL dates. If you're used to seeing "2019-13-10 08:00AM" it would be confusing for you to have to enter it as "2019-10-13 08:00AM", just as it would confusing for Americans to have to enter "2019-13-10".
At any rate, it is a fact that SQL Server will, depending on specific settings, sometimes interpret a datetime entered in YYYY-NN-NN format as YYYY-DD-MM and not YYYY-MM-DD. Therefore, a date format with dashes is undeniably ambiguous.
Thus, for date literals, you should always use YYYYMMDD, period. Yeah, it's a tiny bit harder to read/process, at least initially, but you get used to it. And that's vastly better than getting invalid results because of an incorrect date conversion/interpretation.
SQL DBA,SQL Server MVP(07, 08, 09) Prosecutor James Blackburn, in closing argument in the Fatal Vision murders trial: "If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them."