Because you're consuming memory and resources intended for the SQL Server process, 1, and 2, it means your SQL Server service account doesn't have to have special privileges within the domain (because that's what it execute in the context of). Also, it means you can put in more extensive error handling, decision trees, etc., in to an application if it queries SQL Server for the information and then makes a determination of what needs to be updated, etc., within the application. Also, by doing so, you're making the solution more portable, meaning you could put it on a utility server and move it around as needed as opposed to installing something custom into SQL Server.

So yeah, several reasons. Also, it's the general idea that this isn't what SQL Server was intended for. SQL Server was intended to service as a database engine, so it's not really the right tool for the job, even though you might extend it some. It was like the idea of using Microsoft Exchange to store files. While it was technically supported, Exchange would never do it as efficiently as a regular file system or a document control system like SharePoint (which is extremely lightweight with respect to feature set in this category but still performs better than Exchange).