Hey Bob,
I see your dilemma, as it's a common one when dealing with already-existing stored procs. First, this is a great BizTalk paper on the SQL Adapter (http://msdn2.microsoft.com/en-us/library/ms935658.aspx), so check that out.
To your point, I wouldn't say that using a component to call a proc is "bypassing standard BTS functionality." When using the SQL Adapter, one of the primary "value adds" is the generation of schemas. That's not really useful in your case. Given that you're just getting a value back from your call, you could still store that value in an orchestration variable, and use the BizTalk workflow to drive a next step based on it. The SQL Adapter is just one piece that you can choose to use, or ignore. There's still lots of other interfaces you can talk to besides SQL, and the workflow piece doesn't really care where the data comes from!
Does that help at all?