(dwebb) - That really is the question.  As (bozo7) put it, it seems as though most people do not take advantage of multiple ownership of objects, which, based on my experience, I would have to agree... it seems to be a level of "complexity" that many administrators oftentimes don't take the time to investigate, and admittedly, in many environments may not be the appropriate way to architect the system anyway.

So, that truly does beg the question:  Is this the appropriate "worst practice" in an environment that ONLY utilizes dbo owned objects?  As the article pointed out, if you ever STARTED to take advantage of user-based ownership of objects in the database, then the "dbo" qualification can work to your advantage in applications that have been constructed in that manner.

But, as (dwebb) asked, is there a true performance difference in an environment that aliases everybody to dbo?  If you NEVER qualify any of your objects, and always assume dbo, are we really gaining anything?  I.e., will we wind up with a cache hit or not? 

If so, then from a performance standpoint, this is a non-issue.

If not, then why?  If all of the objects are owned by the exact same user, and that user is dbo, and this configuration is utilized by the majority of SQL environments (ok, big assumption there, but...), woudn't it only make sense to assume dbo first, always, and forever, amen, REGARDLESS of whether we tell the system that this is the object we mean?