In this particular business scenario, as far as I know, Native SQL is the only way to achieve the required results i.e. it is not possible to construct a generic Open SQL statement to provide a solution for this requirement as there could possibly be innumerable search combinations.
Other way it could have been done was to use direct Native SQL operations i.e. coding direct EXEC-ENDEXEC statements - but there are lots of advantages of using these ADBC APIs. The intention is not to touch the core object (Native SQL operations) but to work with the wrapper objects (the APIs) which drive the DB operations with a lot of exception handling at each layer available "free" to the calling applications.
I think the whole point is to model the data access in an object oriented approach.To put this argument into perspective: Would I write procedural code if asked to write a new program from scratch? No. Is there any harm in writing good procedural code? No. Then why would I write it in OO then? Because I want to implement the solution that encapsulates a 'Model' which then becomes much easier to enhance and/or extend business functionality in the long run etc. etc.
So I think, more often than not, there are more than enough reasons for being elegant than just doing it for elegance sake! 
Sougata.