we have no plan to change this fact, sorry

And yet

doesn't print as ODBC date literal

but as ODBC timestamp literal

in Lucee. Seems inconsistent to me.

How about a backward compatibility option?
[ _ ] Make createDate, createTime and createDateTime return OLE DB objects/OleDateTime (CFML Default).

this is an incompatibility we decided to have, a solution i see is to add the possibility for a format to the application.cfc influence the output.
something like

Incompatibility? YES

toString(<date>)
this difference is not by accident.
As you can see, ACF has the date "1899-12-30" what is equal to 0, because no date exist.
https://trycf.com/gist/719ed8ca32f5fd6d29e2316631421e13/acf?theme=monokai

the string generated is a "ODBC Literal" i assume Allaire back then has choosen that format because all datasources did support it (and still do).

So now() for example create a datetime object what then is converted to a {ts ''} String (timestamp ODBC literal)
and as you have seen createTime() creates a time object what then is converted to a {t ''} String (time ODBC literal)
in a database the type "time" is not equal to timestamp (datetime).
Because of that in our opinion ACF behaves wrong here, by creating a timestamp string out of a time object.

<date>.toString()
a datetime object from Lucee extends the class java.util.Date, we kept the original behaviour of the toString method of java.util.Date to make it more compatible when you use this class within java code.
We could consider to add a member function "toString" for datetime, that would solve the issue without affecting the class itself when used in Java.

Workaround
Actually a workaround is very simple.
overwrite the "createTime" function with your own implementation by adding "createTime.cfm" to "lucee-server/context/library/function" with the following content (untested).