As well as OLE 2.0 and ODBC Driver Manager 3.5 and higher supports UNICODE strings, Sequel also takes advantages of this coding. To fully benefit from it, Sequel's Client, your application, and ODBC driver must support it. If your application converts ANSI strings to UNICODE, it's only up to you how to handle that. But if ODBC driver doesn't, then it is up to ODBC Driver Manager to convert a UNICODE string passed by Sequel to ANSI one and to pass it to driver. Nevertheless with taken of binary data, ANSI string may be legally passed to ODBC driver. Of course such driver must at least support conversion from binary data to string. In this case do not call IDataValue.BinaryIsString method.
If ODBC driver doesn't expose an ability to handle strings in UNICODE, it doesn't mean that it can't do that yet. E.g. MS Access driver of version 4.0 will not expose this for data file format less than 4.0 (this is not version of MS Access), but it will transfer strings as UNICODE ones if being passed as binary data. Generally it is not recommended to use such tricks.
When reading strings, Sequel always got them from ODBC Driver Manager as UNICODE ones. Therefore you are the only one who convert them from UNICODE to ANSI. This applies for result set as well as for IDataSource and IDrivers.