The representation of dates as character strings in a database (what I'll call a "VarDate") is one of the leading causes of business intelligence disasters.

The day will come when another peripheral application or ETL process will start inserting into or querying from your database, and they won't follow (or be aware of) the assumption for how the "VarDate" should be formatted.

Other RDBMS like Oracle follow different rules about how they implicitly convert data types. For example, SQL Server will reliably convert YYYY-MM-DD or YYYYMMDD to a Date, but Oracle will only implicitly convert a char value in the format 'DD-MMM-YYYY' or 'DD-MMM-YY'.

An even worse scenario than implicit conversion that throws an error is an implicit conversion that works, but works in a way that you didn't expect. The application appears to be running normally, but you discover months down the road that payroll or invoices submitted to clients been totaled incorrectly or duplicate records have been entered into tables where a VarDate column is part of the primary key.