Your question requires a bit more context in regards to what your end goal is.
If your goal is to provide some sort of popup where the user can select features based on a SQL query and see them highlighted on the map, you do not need geoprocessing or SLBA. You just want to use some sort of query task or widget in a web application. Check out the query widget in the web app builder (WAB)
If your goal is to do some sort of query and then do something with those selected features, like buffer or hot spots, etc, then SLBA inside a tool (python script or model), published as a geoprocessing service makes sense. However, geoprocessing services are very closely tied to the data required to run them. So you'd author the GP task using the same data that the map service the web app uses. Technically the map service and the GP task aren't connected in any physical way. Its just the web app always you to display and consume both in 1 spot. Another way to say this: the 2 services may use the same data, but doing a select in the gp service isn't doing a select in the map service. The gp service can send back features and the app will draw the selection. But why do this? (if thats the goal) The query task as mentioned above would make more sense in terms of ease of use and performance.