This is to some extent the beginning of a standards document and I think a good start. Some additional thoughts:

I think developers should be discouraged from creating a new database for each application, instead favoring having databases for related needs (related in particular by where they are needed, replication needs, backup needs). This reduces the number of databases to maintain.

On a related note, if developers can create databases there needs to be a thorough process to make sure all the admin details are worked out -- how will it be backed up, reorged, etc. Otherwise it is very easy to have little islands of applications and discover one day you can't recover it when something happens.

A whole 'nother big topic, but I think blankent recommendations against dynamic sql are a mistake. Depending on your definition of "ad hoc" especially. If the code has parameters driven by user input and those parameters can vary radically (especially being null), AND if the queries will have long run time (more than seconds), then dynamic SQL is often preferred because it allows for better query plans. Complex queries driven by parameters often have lots of OR statements in them (e.g. @Param is null or Field=@param) which can be omitted if dynamic. OR statements make for lousy execution plans usually.

I believe any environment that allows or encourages development of databases by programmers also needs a consistent documentation environment -- how and where will data dictionary type information be stored? Make sure it is consistent among all databases, and preferably easily searchable across databases to ensure that similar concepts are recorded similarily (or perhaps not recorded at all redundantly). Strong Naming conventions are a great benefit if the number of contributors to database schemas is large.