Personally, I hate hate hate C-ish libraries when a perlish approach fits much nicer. For example the OpenGL C libraries use something like hungarian notation so the caller can specify what types and how many parameters they pass in:

glGetLightfv
glGetLightiv
[download]

These two functions make no sense in Perl, one is for passing in the number of the light as a floating point number, the other is for passing in the number as an integer number. So, conveniently, there is OpenGL::Simple, which exports only one function and uses Perl (or rather XS) code to determine which function was meant:

glGetLight
[download]

This is possibly slightly less efficient but doesn't burden me with thinking about the parameter count and types, especially when Perl has to convert to the right types anyway.

To answer your question, I like how you provide sensible defaults. You might want to make the other, more specialized C functions available too, but maybe not export them, so one can always still override your "smart" code. But as long as your "smart" wrapper even lives in Perl code, people can always look at it and patch it directly. So I say, go for it and reduce the API by Perl dwimmery ;-)