On the point of the article, about having a "code checker" for SQL, I don't think it would really be possible, at this point, to automate such a system. Databases and procs and such are far too business-specific.

How, for example, would a standard checker know if a proc is taking too long to run, or if it's something that's expected to take a long time, and it's okay/good in this case?

How would a "lines of code" check help in situations like "you have inline UDFs in your Where clause"?

Now, something that could find things like that might be a good idea, but I don't see it replacing running a server-side trace and querying the results in various ways.

On the subject of SQL "needing to go away", I have to ask what you would replace it with. It's a pretty darn effective way to access data. I've used OODBs, and so far as I can tell, they universally stink for anything but building simple web apps on top of, and are a nightmare to build reports on.