Either I am confused or you misinterpret the meaning of "interface".
I am an amateur, so likely it is me.
Interface is for the users... that's why it's called "interface" in the first place... IMO anyway. "convert" does not have any interface that converter developers need to use. In fact, converters are not aware or coupled with "convert" infrastructure. What "convert" says with regard to converters is -- if you want to be incorporated into "convert" framework, you need a certain signature -- it's called a requirement.
How I understood it is that the generic boost::convert<> is a user of the specific converters, it therefore poses requirements on the interface of the specific converters. Where I understand interface to mean the functions and signature they support. If boost::convert<> puts requirements on the interface of specific converters, I do not know why other users of specific converters should not take advantage of those. Furthermore, it seems boost::convert<> extends the (shared) interface of specific converters, i.e. it provides convenience functions.
Whereby the boost::convert<> acts as the middle man. Anybody looking for efficiency will consider eliminating the middle man.
... if you really care for efficiency, try compiling optimized and then try finding that "middleman" anywhere. :-)
I found him: he is performing a default construction that is not always necessary. But there are other forms of efficiency too. Such as reducing dependencies and writing more compact and expressive code.