Is there a technical issue that flat out prevents it?

Yes there is - maybe not "prevent" it from ever happening, but certainly "makes it more difficult to implement". In general, our ODBC driver targets ODBC version 3.5, due to general compatibility concerns with third-party ODBC driver managers on UNIX operating systems (e.g. unixODBC, and iODBC). From: http://msdn.microsoft.com/en-us/library/bb677267.aspx

Because ODBC does not permit driver defined C types, SQL_C_BINARY is used for time and datetimeoffset as binary structures.

and: http://msdn.microsoft.com/en-us/library/windows/desktop/ms714822%28v=vs.85%29.aspx

In ODBC 3.8, you can specify driver-specific C data types. This enables you to bind a SQL type as a driver-specific C type in ODBC applications when you call SQLBindCol, SQLGetData, or SQLBindParameter. This can be useful for supporting new server types, because existing C data types might not correctly represent the new server data types. Using driver-specific C types can increase the number of conversions that drivers can perform.

For example, suppose a database management system (DBMS) introduced a new SQL type, DATETIMEOFFSET, to represent the date and time with time zone information. There would be no specific C type in ODBC that corresponded to DATETIMEOFFSET. An application would have to bind DATETIMEOFFSET as SQL_C_BINARY and cast it to a user-defined data type. Beginning in ODBC 3.8 with C data type extensibility, a driver can define a new corresponding C type. For example, for the new SQL type DATETIMEOFFSET, the driver can define a new corresponding C type such as SQL_C_DATETIMEOFFSET. Then, an application can bind the new SQL type as a driver-specific C type.

A C data type is defined in the driver as follows:

The ODBC compliance level for an application, ODBC driver, and Driver Manager is 3.8 (or higher).

So we would have to re-target our ODBC compliance level for our ODBC driver and then third-party ODBC managers have to implement ODBC 3.8, in order to make such a change fully work.

I've found that Entity Framework, at least, happily maps TIMESTAMP WITH TIME ZONE to System.DateTimeOffset.

This is a string to native type mapping that happens inside the provider. It's still returned as a string back from the database underneath the covers.

Is there a specific issue are you encountering due to this issue? Most of our customers are able to use the TIMESTAMP WITH TIME ZONE type directly as a string.