Luis Cazares (11/4/2015)
Some of us prefer to avoid prefixes for most objects. Procedures should just be descriptive on the action they perform. Adding a prefix only slows down coding.
When creating an object without specifying the prefix, SQL Server will have to take extra steps to look up the default schema for your userID. That's just a minor performance overhead but it can be avoided.
When accessing an object without specifying the prefix, SQL Server will first have to take those same extra steps (same overhead, but accessing objects occurs more often than creating them so it can become more of an issue). It will then check if the object exists in that schema. If it doesn't, it will then check if the object exists in dbo. All that together adds up to a significant performance overhead.
Worse than this: any query (and that includes queries in the context of a stored procedure!!) will have its execution plan marked as unsafe for reuse. You may end up getting a copy of each execution plan for each individual user. That is because for a different user, the same object name might resolve to a different object (based on default schema).
Probably even more important, SQL Server will allow objects of the same name to exist in different schemas. This can result in weird and hard to explain "bugs" if someone creates a new object in schema X when an object with the same name already exists in schema dbo - for some users, the same stored procedure can suddenly produce incorrect results because a query now resolves to the new object in schema X.
Trading four keystrokes for a combination of various performance hits, extra pressure on the procedure cache, extra compilations, and a chance of incorrect results does not sound like a good trade to me.