While I agree with the essence of the previous posts, saying something is "nonsense" without constructively suggesting alternatives or even saying why is not helpful.

As for a statement like "never use abbreviations or acronyms", well ne dis jamais jamias (never say never).  As long as they are used sparingly and consistently I don't believe there will be problems.

I was dismayed to see the word "Data" included in one of the database name samples.  Terms like "Data" and "Information" should rarely if ever appear, as they add no descriptive value.  Was the db for an OLTP/TPS or a Mart? Well then say so in the name.

Your backup files suggestion is fair, and I have seen variations commonly used.  Although one could argue where environments keep the date and time as displayable/sortable file metadata, why bother with putting it in the file name?

In my experience, prefixing tables with a "t" (and views with anything) is unnecessary and counter productive.  For the most part, when doing development or maintenance, the person on the job always has the context of the object readily available, if not in the forefront of thoughts.  In any event SQL Server will easily tell you whether an object is a view or table or whatever.  Even when writing queries an objects "tableness" or "viewness" is not relevant.  Tables will have simple, short names when named correctly.  I believe they should be named in the plural (e.g., Users), although I keep entity-type names in data models singular.  View names tend to longer than table names because they should also describe the view's purpose with an allusion to whats in the where clause and/or whether its a UNION or OUTER JOIN and so on. 

In column names I think classwords add value.  I think "ID" should be used anywhere it makes sense (e.g., UserID), but always used as the classword for surrogate keys.  PhoneNumber is a much better name than Phone, as the Number classword means fixedlength string primarily comprised of digits. In my opinion, using prepositions like on and by should be avoided; classwords tend to make the column name clearer, as in CreateDate, CreateUserID.

I also think use of prefixes on columns indicating "indexness" or "keyness" is pointless and serves to obfuscate.

I could go on with more suggestions, but I've spent enough time on this already.  I hope my suggestions will give the author and other interested parties something to consider.

Regards all - Todd