Whilst I agree that IP Tables would be faster than a database lookup, I'm not sure the bottleneck is with the query itself.
My two areas of concern are the Select statement with multiple string comparisons, which is used to convert from a language name to a number, and the variable column selection. Both of these would remain an issue.
Where an IP Table may very well help is with the removal of the Select statement. Assuming my previous suggestion (prefixing the string with an integer which you can strip off and convert) isn't workable, then you could use an IP table to lookup the language and return an integer. Given the number of languages, this may very well be the most efficient method and also allows for future languahe additions without modifying the code - always a good thing!
I agree totally that using REST or SOAP would add an additional layer to the process, although this may not be all bad. After all, abstracting it in this way would mean that changing the database back-end at a later date would be much easier. It also would allow the entire process to be handled within Attendant, since neither IP Tables not Stored Procedures are currently supported there. Unfortunately, unless I have missed something, Attendant cannot currently make direct use of REST, so for this solution, if it's to be handled entirely in Attendant, it'd have to be SOAP.
My reason for suggesting a Stored Procedure is to allow for the variable column return. PureConnect is not a data-processing application, so it's support for complex data analysis is somewhat limited. Using an SP, you could pass the row and column required and have it return the value, without tedious post-processing in a Handler. I agree that the actual call may not be more efficient, but I believe the overall process would be.
Finally, I have to respond to your question. I believe that for the most efficient workflow, and the most supportable end result, as much as possible should be completed within Attendant and subroutines only called to perform the minimal amount of work that cannot be achieved any other way, immediately returning control to Attendant for the heavy lifting. Consider the "Play a Menu" Operation. It handles playing the prompt in the chosen language, repeating the playback, default options, possibility of Speech Recognition integration and, most importantly, it is fully tested and it works. To replicate that one operation in Handlers involves a lot of code, with subsequent testing and then the possibility of still having errors. Furthermore if it is enhanced in a furture release, then the enhancements would not be available to the custom code. This is just one example, consider "Caller Data Entry" or pretty much any of the operations.
HTH