Keep in mind that as either a member of the db_owner or db_ddladmin role, you could create objects that are dbo owned. We make it a standard practice where I work to include owners on all object creation statements just as a general rule so the extra 4 characters per object isn't a concern for us. However, if that isn't a standard practice, I can see the issue.

One of the issues with using aliases is they don't show up in Enterprise Manager. While the information can be seen by executing the T-SQL commands, a lot of DBAs rely on EM because it's quick and easy. When dealing with users and roles, I'll admit I use it a lot myself. That's one of the main issues I see with it.

Another issue is there may be cases where you don't want anyone accidentally touching certain objects in the "wrong" way. For instance, you have a lookup table and there shouldn't be any INSERT, UPDATE, or DELETE statements run against it. Yet you have folks that need to have basically db_owner permissions (this is a rare case, but it is possible). The dbo user bypasses all permissions. Members of the db_owner role do not. Therefore, the table could be set with DENY INSERT, UPDATE, DELETE to public and those who were a member of the db_owner role (but not mapped or aliased to dbo) could do what they needed to do within the database, but they couldn't accidentally change data in the table.