Good question. Too bad the explanation is lacking. It explains how to work around the issue, but not what causes it.
The answer to that is data type precedence. Both VALUES and "SELECT ... UNION SELECT ..." are expressions that can be used at various places, not just in an INSERT. Expressions that return a resultset - a set of zero*, one, or more rows, with one or more columns. Each of those columns has to have a single data type. And that data type is determined by those rules of data type precedence.
In this case, the input matches two data types: date and varchar. Date has a higher precedence than varchar, so the resultset of both the VALUES and the UNION'ed queries is defined as having a single column with data type date. This means that the varchar value will be explcitly converted - and that is what causes the error. If you modify the question to replace the varchar value '10' with a value that does convert to date (eg '20130611'), you'll get no errors, and two rows in the returned result. That have come there after first] converting the varchar value '20130611' to its date equivalent, and then converting both that date and the other (unconverted) oct 10 date to varchar, for inserting in the table.
Explicitly casting the date argument to varchar fixes this because (a) that cast succeeds, (b) now both inputs for VALUES / UNION are the same data type (varchar), so no conversion is required, and (c) the result of that VALUEUS / UNION is also already the correct data type for immediate inserting in the table.