The robustness of an database application system can be increased when the application does only rely on the database schema, but not (or at least not too much) on its content.
SQL needs to be treated exactly as any other piece of source code - it has to be written by a developer, it needs some tests (ideally automatic tests), it has to be versioned, it has to be maintained, and when it breaks is has to be debugged.
Now when you have SQL queries which are tightly coupled to your applications code, so they are designed for working with a specific version of your application, it does not matter if those queries are stored in the database or directly in the application - they are effectively part of the application in both situations. And when you need to deploy a new version of those queries - if they are stored in the database, in a config file or elsewhere - it is effectively as if you deploy a new release of your software: the whole system (applications + SQL) needs a new version number, the system as a whole needs to be tested, maintained and sometimes debugged.
If, for some strange reason, you have in your environment better control over deploying new SQL queries as database content than over deploying new releases of your application, then you might prefer to use this for your advantage. But that is actually not a "smart technical solution" or a "best practice" - that is simply a backdoor for deploying new code without proper release management for something which deserves the latter. And you have to make sure 100% no user, power user or admin starts to fiddle around with those queries. Not necessarily intentional, but what if a db admin restores a backup of the database from last week, with the old queries, whilst your application's version is the one from this week, and both don't match?
If this comes to the worst, you might get a strange support call from your customer why the application is not working as intended, but the version number of the application will tell you nothing about the SQLs your customer has in his database and which might be the cause of the problems.
So my recommendation here is: don't "outsource" parts of the application which are effectively tightly coupled to it to another place, just because that "other place" allows a different release cycle. Better work on making the deployment of new releases of your application (including updates, hot fixes etc) less painful. You will surely have tons of other requirements or issues for which quick deployment of the application in less than, lets me guess, 24h hours, may be benefical. If you solved that problem, there will be no need to create any workarounds like storing SQLs outside of your application any more.
EDIT: Some note on the suggestion of using a web service as an "interface between your application and the 3rd party DB": this gives you indeed better control over the release management, since it allows one to manage releases of the application, the db and the service independently. The service then will not just take responsibilities over SQL queries, but also over the way the system connects to the 3rd party db. If the 3rd party might change the whole DB system or the connection policies, you can solve this without redeploying the application (but by redeploying the service, of course).
However, this does not come for free: you add an additional layer of complexity to your system. Moreover, the whole communication between you application and the 3rd party DB then does not run directly between the the application and that DB any more, but over the web service, which might become a bottleneck. So you need to check carefully if this step from a simple two-tier application to a more complex 3-tier application is really worth it.